From owner-freebsd-arch@freebsd.org Fri Dec 27 17:53:27 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF4491CA9A1; Fri, 27 Dec 2019 17:53:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47kvZH09yZz4Mtp; Fri, 27 Dec 2019 17:53:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-yb1-xb29.google.com with SMTP id w126so9622992yba.3; Fri, 27 Dec 2019 09:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:cc:from:subject:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=CqVXPeAhfkK6BEgC3DQUkYZdKvnPnoJ1+kbTC1Jt/TY=; b=JMqqlowRfMUirHusZMSt91sOzO5iFiUxTGOpTPLM7l2HFkMv4iT+Kq4x3IWQHwTBP5 cWiUdAbM7VPgWQJENpG8t3njzDVVBNtbQlRTh7XuUGlHAd5cMm15Lvh9Ra99cZ7XvXxK iDhuV8SOL+ylt2mIwJ6/To6PG2EFoRQNBiGlE8YrTJE5gdzzLtiz4bhFRdoMzxT2YOiH 9CMZ/OXBDRPyhpIKupe6z0Ow8crWDPxxsAW0MzORWHKjvKjRF8LRURciOxcwtiYSC06+ ObwtfDmE6Qfovc3yiN+J+FIqJ3T7OLLs3Am5UYHXLPxk5wvR0G2c4B9CYgvw/0AKbUXw Qwvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:cc:from:subject:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=CqVXPeAhfkK6BEgC3DQUkYZdKvnPnoJ1+kbTC1Jt/TY=; b=sb5VSdXyV+0o1szEJaNOASI1eVPyZqezTA1AiIxL8zQUJFEJVgzh8OXfGtrZ3DdoKp HX4u6oEKiRwJgdaVyDa4Ao+2iRDvxXgJMldUWK2Ut8kLiRt5QAqw2jgHxZ2nqNdokfUT T+H00ACsk5on4xx5BXOpqHMC6GCgLT3zI2DNml1p7oQfpmqUmvenJoyrMgVW+bu68n9G I2FU89Dd6cl2DuUjcb1j0KsfFwydgH77SB2R2znTh68uNH3C9bA4Nq+zu/rkWunRAZPi biDA5VZk/rnTArMaZKEukj+y1fTyc4p9/qDsaCVT8UrVjUn7pIZY/TTJ0tDGIMZ9Xczn A1xQ== X-Gm-Message-State: APjAAAXFSLcYhGYlG4mt79E0DA4Mum3PlQBX8uv8TX3HVuK49WBHrlOJ Vbgg+3ox6ndsc4pR2esYlT8qlwwT X-Google-Smtp-Source: APXvYqykzGMFExM6CsfoeIu8Z7STAhTOGRRTgdu087UJ2b1DCEZN03V1lsCvJVPbSdrv1lptq+UJAA== X-Received: by 2002:a25:2901:: with SMTP id p1mr36186321ybp.75.1577469205690; Fri, 27 Dec 2019 09:53:25 -0800 (PST) Received: from mavoffice.ixsystems.com ([12.189.233.129]) by smtp.gmail.com with ESMTPSA id y206sm14275095ywa.102.2019.12.27.09.53.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Dec 2019 09:53:25 -0800 (PST) Sender: Alexander Motin To: "freebsd-geom@FreeBSD.org" , "freebsd-arch@freebsd.org" Cc: Warner Losh , Luigi Rizzo , "Andrey V. Elsukov" , Pawel Jakub Dawidek , "Conrad E. Meyer" From: Alexander Motin Subject: gsched: modernize or remove? Autocrypt: addr=mav@FreeBSD.org; prefer-encrypt=mutual; keydata= mQENBFOzxAwBCADkPrax0pI2W/ig0CK9nRJJwsHitAGEZ2HZiFEuti+6/4UVxj81yr4ak/4g 9bKUyC7rMEAp/ZHNhd+MFCPAAcHPvtovnfykqE/vuosCS3wlSLloix2iKVLks0CwbLHGAyne 46lTQW74Xl/33c3W1Z6d8jD9gVFT/xaVzZ0U9xdzOmsYAZaAj4ki0tuxO9F7L+ct9grRe7iP g8t9hai7BL4ee3VRwk2JXnKb7UvBiVITKYWKz1jRvZIrjPokgEcCLOSlv7x/1kjuFnj3xWZU 7HSFFT8J93epBbrSSCsYsppIk2fZH41kaaFXsMQfTPH8wkeM6qwrvOh4HiQM08R+9tThABEB AAG0IUFsZXhhbmRlciBNb3RpbiA8bWF2QEZyZWVCU0Qub3JnPokBVwQTAQoAQQIbAwULCQgH AwUVCgkICwUWAwIBAAIeAQIXgAIZARYhBOmM88TmnMPNDledVYMYw5VbqyJ/BQJZYMKuBQkN McyiAAoJEIMYw5VbqyJ/tuUIAOG3ONOSNYqjK4eTZ1TVh9jdUBAhWk5nhDFnODN49Wj0AbYm 7aIqy8O1hnCDSZG5LttjSAo3UfXJZDKQM0BLb0gpRMBnAYqO6tdolLNqAbPGJBnGoPjsh24y 6KcbDaNnis+lD4GwPXwQM+92wZGhCUFElPV9NciZGVS65TNIgk7X+yEjjhD1MSWKKijZ1r9Z zIt4OzUTxxNOvzdlABZS88nNRdJkatOQJPmFdd1mpP6UzTNCiLUo1pIqOEtJgvVVDYq5WHY6 tciWWYdmZG/tIBexJmv2mV2OLVjXR6ZeKmntVH14H72/wRHJuYHQC+r5SVRcWWayrThsY6jZ Yr4+raS5AQ0EU7PEDAEIAOZgWf2cJIu+58IzP2dkXE/urj3tr4OqrB/yHGWUf71Lz6D0Fi6Z AXgDtmcFLGPfMyWuLAvSM+xmoguk7zC4hRBYvQycmIhuqBq1jO1Wp/Z+lpoPM/1cDYLn8Flv mI/c40MhUZh345DA4jYWWaZNjQHUWVQ1fPf595vdVVMPT/abE8E5DaF6fSkRmqFTmfYRkfbt 3ytU8NdUapDcJVY7cEP2nJBVNZPnOIObR/ZIgSxjjrG5o34yXoqeup8JvwEv+/NylzzuyXEZ R1EdEIzQ/a1nh/0j4NXtzZEqKW4aTWlmSqb6wN8jh1OSOOqkYsfnE3nfxcZbxi4IRoNQYlm5 9R8AEQEAAYkBPAQYAQoAJgIbDBYhBOmM88TmnMPNDledVYMYw5VbqyJ/BQJZYMLYBQkNMczM AAoJEIMYw5VbqyJ/TqgH/RQHClkvecE0262lwKoP/m0Mh4I5TLRgoJJn8S7G1BnqohYJkiLq A6xe6urGD7OqdNAl12UbrjWbdJV+zvea3vJoM4MZuYiYrGaXWxzFXqWJcPwMU9sAh8MRghHu uC5vgPb45Tnftw9/+n0i8GfVhQhOqepUGdQg4NPcXviSkoAvig6pp9Lcxisn0groUQKt15Gc sS9YcQWg3j9Hnipc6Mu416HX98Fb113NHJqc2geTHLkRyuBFOoyIqB6N9GKjzOAIzxxsVdl9 TevwGsrp4M4/RFzWbSgsbOnbE7454lmuVZGfReEjnUm8RHp9Q2UWKXlp3exlZjvOp/uVEpCg lz65AQ0EU7PEDAEIAOZgWf2cJIu+58IzP2dkXE/urj3tr4OqrB/yHGWUf71Lz6D0Fi6ZAXgD tmcFLGPfMyWuLAvSM+xmoguk7zC4hRBYvQycmIhuqBq1jO1Wp/Z+lpoPM/1cDYLn8FlvmI/c 40MhUZh345DA4jYWWaZNjQHUWVQ1fPf595vdVVMPT/abE8E5DaF6fSkRmqFTmfYRkfbt3ytU 8NdUapDcJVY7cEP2nJBVNZPnOIObR/ZIgSxjjrG5o34yXoqeup8JvwEv+/NylzzuyXEZR1Ed EIzQ/a1nh/0j4NXtzZEqKW4aTWlmSqb6wN8jh1OSOOqkYsfnE3nfxcZbxi4IRoNQYlm59R8A EQEAAYkBPAQYAQoAJgIbDBYhBOmM88TmnMPNDledVYMYw5VbqyJ/BQJZYMLYBQkNMczMAAoJ EIMYw5VbqyJ/TqgH/RQHClkvecE0262lwKoP/m0Mh4I5TLRgoJJn8S7G1BnqohYJkiLqA6xe 6urGD7OqdNAl12UbrjWbdJV+zvea3vJoM4MZuYiYrGaXWxzFXqWJcPwMU9sAh8MRghHuuC5v gPb45Tnftw9/+n0i8GfVhQhOqepUGdQg4NPcXviSkoAvig6pp9Lcxisn0groUQKt15GcsS9Y cQWg3j9Hnipc6Mu416HX98Fb113NHJqc2geTHLkRyuBFOoyIqB6N9GKjzOAIzxxsVdl9Tevw Gsrp4M4/RFzWbSgsbOnbE7454lmuVZGfReEjnUm8RHp9Q2UWKXlp3exlZjvOp/uVEpCglz4= Message-ID: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> Date: Fri, 27 Dec 2019 12:53:24 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47kvZH09yZz4Mtp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JMqqlowR; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::b29 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-3.81 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-2.61)[ip: (-8.94), ipnet: 2607:f8b0::/32(-2.16), asn: 15169(-1.88), country: US(-0.05)]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[9.2.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 17:53:28 -0000 Hi, As I can see, gsched code was not really maintained for the last 10 years since being added. It misses many GEOM features added later, such as direct dispatch, unmapped I/O, stripesize/stripeoffset, resize, etc. Even if some of them may require just a proper declaration, it tells me that barely anybody used it seriously for years. But my primary concern is the `gsched insert` implementation. Right now I got to it since it is the last consumer of nstart/nend counters in GEOM, which I would like to remove for performance reasons. But I also see tons of potential problems with idea of moving providers between unaware geoms. So my question is: does it make sense to try fix/modernize it, or it just be easier to remove it? Does anybody still use it, or see some future for it? -- Alexander Motin From owner-freebsd-arch@freebsd.org Fri Dec 27 19:49:17 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8AE7B1CD4E4 for ; Fri, 27 Dec 2019 19:49:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47ky7w5hx9z4V5t for ; Fri, 27 Dec 2019 19:49:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf36.google.com with SMTP id m14so10386220qvl.3 for ; Fri, 27 Dec 2019 11:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KzMs03Aq7gxS3S651YRiHs9bHgcKA85ZOVpl5CTlK8w=; b=HqBCQFZhmM8DXMXDxjF0Tsk4FN3lWjyLJ5ZWJO8Gy5sKVJA7wbHuxVdhD4RF6ZVfc4 DJju6+0bzwDCADeBR7H6Zuy6/TA0tm25oBs/dlFIl7xn4A/7UQMpW73t1XWF+wyBydmE kbhB5Gq767QCcvRdgrQ9XyJHkteG6vI2S16aPd+yAYYG9rnSlHybCiZ5h7Bb8H9esuXl RKpeDjllU26awcG+W5hVESSSWDrVCFdqyLGlVLraDuWeAZa7+J7HNjo+WM2x027ijF65 razvbYtNSbV/7x5uMgQWHIHjr5YR2BpX3yxMgvjAee9wtwkRPUl+ji2CTz4oPB7AX93v bj5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KzMs03Aq7gxS3S651YRiHs9bHgcKA85ZOVpl5CTlK8w=; b=R9TEmsEm2DV0AJqOi3bdMLYAljhQYh4s9vjrfUlUvxCthT91IG5A1un+vbaIqXsGxA xVIoT0X+bPHSGFgyoP00NkuYqYo51YEPgFRC4ROCqt3wGWwDVpn8ykaRhHq6Q/phrorK MStzBFfJsls/w54UbHVMg46Gokxokhg9J6FLiARY0EMhLrw4Hxgzo3g4QWIvOt2RmKq2 2pOzEeaVYBEYWGJ6LCzMeRh69oFsZYyHv2e8FxTZ1Xg4e/pw9GPH1N/CYe/BuzQiQbEr q20TsFmemkQpBbc0jo4toZgBKJrBj64DNen90uEwtPaxrSirmcKFC+CvvRAnVblkEJNg KH9Q== X-Gm-Message-State: APjAAAXw67CaK4GNLfFXRaxL/ee0gy2O9mQyV+YFUqDm2XbHD49Halhg 6la7kBabAQfnRW4Tll1tIwgsCtJ1B+vaQFm5Zjiy2w== X-Google-Smtp-Source: APXvYqwxZqtkbkVPQWUTbqpJd03XT0xoLJQKdMfpHe6kLYdUWV90dANd0C6vJhWxWWFZo3bvTx2NwqLE9mcro+0DUHA= X-Received: by 2002:a05:6214:965:: with SMTP id do5mr26532700qvb.202.1577476155687; Fri, 27 Dec 2019 11:49:15 -0800 (PST) MIME-Version: 1.0 References: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> In-Reply-To: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> From: Warner Losh Date: Fri, 27 Dec 2019 12:49:04 -0700 Message-ID: Subject: Re: gsched: modernize or remove? To: Alexander Motin Cc: "freebsd-geom@FreeBSD.org" , "freebsd-arch@freebsd.org" , Warner Losh , Luigi Rizzo , "Andrey V. Elsukov" , Pawel Jakub Dawidek , "Conrad E. Meyer" X-Rspamd-Queue-Id: 47ky7w5hx9z4V5t X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=HqBCQFZh; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f36) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.82 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.82)[ipnet: 2607:f8b0::/32(-2.16), asn: 15169(-1.88), country: US(-0.05)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_SEVEN(0.00)[8]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 19:49:17 -0000 On Fri, Dec 27, 2019 at 10:53 AM Alexander Motin wrote: > Hi, > > As I can see, gsched code was not really maintained for the last 10 > years since being added. It misses many GEOM features added later, such > as direct dispatch, unmapped I/O, stripesize/stripeoffset, resize, etc. > Even if some of them may require just a proper declaration, it tells me > that barely anybody used it seriously for years. But my primary concern > is the `gsched insert` implementation. Right now I got to it since it > is the last consumer of nstart/nend counters in GEOM, which I would like > to remove for performance reasons. But I also see tons of potential > problems with idea of moving providers between unaware geoms. > > So my question is: does it make sense to try fix/modernize it, or it > just be easier to remove it? Does anybody still use it, or see some > future for it? While it's kinda cool, I'm not sure it has stayed relevant enough. It's kinda at the wrong layer to do effective scheduling since the low level drivers get to pick and choose what goes to the drive when. We had a lot better luck tweaking performance doing this at the bottom of CAM. We've noticed that we like could do a bit better if we can have more coordination with the upper layers. We've not done a lot there yet, but it seems like gsched is in the middle and has the worst of both worlds: it's too low in the stack to control pacing from the upper layers, and it's too high in the stack to effectively control doling out the I/O operations to the device. So I think I'm more on the 'remove' side than the 'improve' side of your question. I wouldn't oppose someone doing a lot of work here if their workload benefits better from it, but I don't think we should do it just because we have it in the tree. It's getting in the way, so my bias is towards removal. Warner From owner-freebsd-arch@freebsd.org Fri Dec 27 22:00:44 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CE0E1D0B12; Fri, 27 Dec 2019 22:00:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47l13b309gz4cF2; Fri, 27 Dec 2019 22:00:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 825FA1AF135; Fri, 27 Dec 2019 22:00:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id xBRM0fst022561 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 27 Dec 2019 22:00:41 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id xBRM0e5Q022560; Fri, 27 Dec 2019 22:00:40 GMT (envelope-from phk) To: Warner Losh cc: Alexander Motin , Luigi Rizzo , Pawel Jakub Dawidek , "freebsd-geom@FreeBSD.org" , "Conrad E. Meyer" , "Andrey V. Elsukov" , "freebsd-arch@freebsd.org" , Warner Losh Subject: Re: gsched: modernize or remove? In-reply-to: From: "Poul-Henning Kamp" References: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22558.1577484040.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Dec 2019 22:00:40 +0000 Message-ID: <22559.1577484040@critter.freebsd.dk> X-Rspamd-Queue-Id: 47l13b309gz4cF2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-0.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.52)[-0.520,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-0.85)[-0.853,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[9]; IP_SCORE(0.05)[ip: (0.07), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.10), country: EU(-0.00)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 22:00:44 -0000 -------- In message , Warner Losh writes: >On Fri, Dec 27, 2019 at 10:53 AM Alexander Motin wrote: > >> Hi, >> >> As I can see, gsched code was not really maintained for the last 10 >> years since being added. >> as direct dispatch, unmapped I/O, stripesize/stripeoffset, resize, etc. >> Even if some of them may require just a proper declaration, it tells m= e >> that barely anybody used it seriously for years. But my primary concer= n >> is the `gsched insert` implementation. Right now I got to it since it >> is the last consumer of nstart/nend counters in GEOM, which I would lik= e >> to remove for performance reasons. But I also see tons of potential >> problems with idea of moving providers between unaware geoms. >> >> So my question is: does it make sense to try fix/modernize it, or it >> just be easier to remove it? Does anybody still use it, or see some >> future for it? Gsched was always a weird thing IMO. I was happy to see that you could do stuff like that with GEOM, but for the life of me I could never figure out why you would want to do it with GEOM which is a very low-information environment when it comes to scheduling decisions. I belive the original inspiration was "Anticipatory disk-scheduling" which tries to mitigate some starvation issues which you can have with a normal elevator disksort on systems with very few ioreq sources[1]. With SSDs all but having erased seek-time from the surface of the planet, and huge caches in drives, controllers and pretty much everywhere else people have been able to squeeze one in, it is not even obvious to me if it makes sense to have any disksort in the first place[2], much less gssched. Poul-Henning [1] Imagine one process doing lots of work on the inner tracks and another on the outher track, if either processes is fast enough, it can starve out the other one, because its work is always closer. Traditionally disksorts have had "no changing direction until you get to the extreme request" hacks to ensure some fairness, but that can get to to worst-case-seek-time per I/O request land. [2] Not sure if anybody has looked at this yet, otherwise: Good project to get your hands wet with disk-I/O and benchmarking. NB: Beware of clustering. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .