Date: Fri, 19 Oct 2007 20:21:46 +0200 From: Karsten Behrmann <BearPerson@gmx.net> To: freebsd-hackers@freebsd.org Subject: Re: Pluggable Disk Scheduler Project Message-ID: <20071019202146.7a2cc376@Karsten.Behrmanns.Kasten> In-Reply-To: <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de> References: <20071011022001.GC13480@gandalf.sssup.it> <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_u4LaQi=.EbdLlgeI3g._33m Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > I wouldn't focus on just anticipation, but also other types of > schedulers (I/O scheduling influenced by nice value?) One note on this subject: it will be nice for things like bg-fsck, but it also brings up a point that has been overlooked so far: priority propagation. As far as I am aware, there's plenty of locks that a process can hold while waiting for I/O to complete (directories, snapshots, probably some others I missed) Now, normally when a high-priority thread needs a lock owned by another process, it'll bump up that thread's priority and yield, hopefully freeing the lock up quickly. This is obviously not quite so easy for IO. I haven't quite understood the code involved yet, as far as I can tell turnstiles panic when the lock-owning thread is sleeping. What we'll probably need to do is make priority propagation wake up a waiting-for-io process, which then needs to dig up its IO request (which may be anywhere in geom, but potentially held back by the scheduler) and make sure it's [re]queued with higher priority. If we don't do this, we'll get funny effects with a bg-fsck blocking some high-priority process indefinitely because it happens to be waiting for IO and holding the snapshot lock, on an IO-busy system. If we do this, we may get into significant fun with cutting into geom to allow requeuing, or waste some cpu with polling from the queuing geom. This point may not be immediately obvious to people coming from the IO/filesystem field, but it is something we should keep in mind. So Far, Karsten Behrmann --Sig_u4LaQi=.EbdLlgeI3g._33m Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFHGPW9AksKLoO3vywRAh8RAJ9r8zME85G1X7MyJGmL6SxQmPaHMQCdEs8T 6Mpn37GtxUzdp3gQE2DIP08= =pnKm -----END PGP SIGNATURE----- --Sig_u4LaQi=.EbdLlgeI3g._33m--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071019202146.7a2cc376>