Date: Tue, 20 Jul 2004 18:03:19 +0100 From: Mark Murray <mark@grondar.org> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: scottl@FreeBSD.ORG Subject: Re: I/O or Threading Suffer Message-ID: <200407201703.i6KH3J0l080390@grimreaper.grondar.org> In-Reply-To: Your message of "Tue, 20 Jul 2004 12:39:04 EDT." <Pine.NEB.3.96L.1040720122732.98217B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson writes: > > I'm sure it could. There are some Giant issues related to the UIO stuff > > that bit me in the bum when I removed the NEEDS_GIANT flag from the > > device, but I'm reasonably sure that with careful work this can be > > untangled. > > UIO shouldn't require Giant. Are you sure it still does? EMEMORY It was an issue over (t)sleeping with(out?) a lock held, and replacing the tsleep with a msleep+mutex gave another problem where uiomove() was called with(out?) a mutex held and that was Very Bad(tm). Warner and PHK knew why it was bad; I'm hazy on details. > Are you sure it still does? FYI, I'm not > even thinking you have to mark the whole device driver as not requiring > Giant, just dropping Giant about some of the long running work (and maybe > conditional on the amount of work). For a small random read, it's not > worth it, but for sustained large reads of randomness, it might be > interesting to see what impact it has. We could even consider a yield of > some sort. That sounds easy enough. It may take me a bit of time to get a machine stable enough for testing. Please nag! > Anyhow, up front, it might be sufficient to drop and reacquire giant and > see what impact it has for the test scenario we're currently looking at. Sure. Modulo instability, I'll do it ASAP. M -- Mark Murray iumop ap!sdn w,I idlaH
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407201703.i6KH3J0l080390>