Date: Mon, 2 Feb 2004 13:35:50 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sched_4bsd.c Message-ID: <20040202131218.M741@gamplex.bde.org> In-Reply-To: <20040201180709.V36463-100000@mail.chesapeake.net> References: <20040201180709.V36463-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Feb 2004, Jeff Roberson wrote: > On Sun, 1 Feb 2004, Bruce Evans wrote: > > > On Sat, 31 Jan 2004, Don Lewis wrote: > > > > > On 31 Jan, Jeff Roberson wrote: > > > > jeff 2004/01/31 18:46:47 PST > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > sys/kern sched_4bsd.c > > > > Log: > > > > - Keep a variable 'sched_tdcnt' that is used for the local implementation > > > > of sched_load(). This variable tracks the number of running and runnable > > > > non ithd threads. This removes the need to traverse the proc table and > > > > discover how many threads are runnable. > > > > Traversing the run queues in sched_load() every 5 seconds might be more > > efficient than maintaing the count. > > It might be cheaper, but it is less scalable. Er, I want it because it is similarly scalable and probably cheaper on all scales. Maintaining the count is O(n) in the number of run queue operations, while traversing the run queues is O(n) in the total length of the queues. The total length of the queues (divided by the number of CPUs) should be much smaller than the number of run queue operations (else the machine is overloaded). Traversing the queues is O(n) in the number of CPUs, but that doesn't matter since if there are enough CPUs for it to take very long then there are enough CPUs to spare one for long enough to run it. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040202131218.M741>