Date: Thu, 15 May 2008 12:29:13 -0700 From: "David Schwartz" <davids@webmaster.com> To: <avg@icyb.net.ua> Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: RE: thread scheduling at mutex unlock Message-ID: <MDEHLPKNGKAHNMBLJOLKIEKLMKAC.davids@webmaster.com> In-Reply-To: <482BFBDA.6060705@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> what if you have an infinite number of items on one side and finite=20 > number on the other, and you want to process them all (in infinite = time,=20 > of course). Would you still try to finish everything on one side (the=20 > infinite one) or would you try to look at what you have on the other = side? >=20 > I am sorry about fuzzy wording of my original report, I should have=20 > mentioned "starvation" somewhere in it. There is no such thing as a "fair share" when comparing an infinite = quantity to a finite quantity. It is just as sensible to do 1 then 1 as = 10 then 10 or a billion then 1. What I would do in this case is work on one side for one timeslice then = the other side for one timeslice, continuuing until either side was = finished, then I'd work exclusively on the other side. This is precisely = the purpose for having timeslices in a scheduler. The timeslice is carefully chosen so that it's not so long that you = ignore a side for too long. It's also carefully chosen so that it's not = so short that you spend all your time switching swides. What sane schedulers do is assume that you want to make as much forward = progress as quickly as possible. This means getting as many work units = done per unit time as possible. This means as few context switches as = possible. A scheduler that switches significantly more often than once per = timeslice with a load like this is *broken*. The purpose of the = timeslice is to place an upper bound on the number of context switches = in cases where forward progress can be made on more than one process. An = ideal scheduler would not switch more often than once per timeslice = unless it could not make further forward progress. Real-world schedulers actually may allow one side to pre-empt the other, = and may switch a bit more often than a scheduler that's "ideal" in the = sense described above. This is done in an attempt to boost interactive = performance. But your basic assumption that strict alternation is desirable is = massively wrong. That's the *worst* *possible* outcome. DS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MDEHLPKNGKAHNMBLJOLKIEKLMKAC.davids>