Date: Fri, 20 Sep 2002 17:52:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rik van Riel <riel@conectiva.com.br> Cc: Julian Elischer <julian@elischer.org>, Bill Huey <billh@gnuppy.monkey.org>, freebsd-arch@freebsd.org Subject: Re: New Linux threading model Message-ID: <3D8BC2E5.62B153E1@mindspring.com> References: <Pine.LNX.4.44L.0209201831050.1857-100000@imladris.surriel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Rik van Riel wrote: > > > 4) ... event-driver priority recalculation, instead of > > > recalculating the priority of each task separately > > > > This actually doesn't work. The worst case failure is under > > overload, which is exactly where you don't want it to be. > > What do you mean it doesn't work ? This algorithm is > being used in practice and it works just fine. I've gone into detail in another posting; this is really a *FreeBSD* architectural list, however. By "doesn't work", I mean "fails to yield the predicted results". If you need a graphic example, please write a Linux version of the multiple contending processes benchmark I proposed, rather than a single microbenchmark. It should be obvious, when the incremental value of additional CPU drops from ~75% to ~50%, and then when the load gets high enough to trigger the requeueing onto the "full quantum queue" instead of "the partial quantum queue", it drops to ~25%. > > The scheduling for the BSD scheduler, as was pointed out, takes > > time not run into the priority weighting. > > The Linux O(1) scheduler uses "time not on the run queue" to > determine process priority, this automatically scales when the > system gets busier and busier. So insertion into the scheduling queue is an average of O(N/2)? ;^). > > A granularity of 3 seconds until the disctinction between the two queues > > for enqueueing delayed jobs is realized is really gross. 8-(. > > Yes, it's gross. However, if your system so heavily overloaded > that the sum of all timeslices of runnable processes gets larger > than 3 seconds there isn't much you can do about that. > > kind regards, The point is that the degraded case when that happens gains no thread group affinity benefits, and you basically end up paying TLB shootdown overhead statistically, based on your processes fraction of the total number of threads on the CPU in question. This same degradation will occur if most of your threads are doing disk I/O (e.g. NFS server, with a lot of clients) or network I/O over a loaded or high latency link, or durin a DOS attack. It will happen at precisely the worst time for it to happen. Make a Linux version of the suggested threads benchmark, and run it on old vs. new Linux threads, all other things being equal. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D8BC2E5.62B153E1>