Date: Tue, 25 Jul 2000 11:48:00 -0600 From: cort@fsmlabs.com To: Lars Eggert <larse@ISI.EDU> Cc: Matt Dillon <dillon@earth.backplane.com>, Alan Cox <alc@cs.rice.edu>, hackers@FreeBSD.ORG Subject: Re: clearing pages in the idle loop Message-ID: <20000725114800.M15614@medea.fsmlabs.com> In-Reply-To: <397C8A42.BF52CC4D@isi.edu>; from larse@ISI.EDU on Mon, Jul 24, 2000 at 11:26:10AM -0700 References: <20000719234124.H14543@cs.rice.edu> <39788E48.60F8A59F@isi.edu> <200007211906.MAA19989@earth.backplane.com> <3978A802.E05CC45@isi.edu> <200007221739.KAA31376@earth.backplane.com> <397C8A42.BF52CC4D@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Right, that was the plan with that code. In fact, I saw some improvement in performance when turning the caches off when in the idle task no matter what we were doing in it. It seems that it kept us out of the cache so we didn't evict the working-set of block processes. } The way Cort implemented it in Linux was so that there's a check for new } processes in the loop that clears a page. This is of course slowing it, but } since it's idle time processing, reduction of latency to start a new } process (and being transparent to foreground processing in general) is much } more important than optimized execution. } } This is also why turning off L1 and L2 caches may be interesting - if one } process blocks, you do some idle time processing and it unblocks, the L1 } and L2 cache may be polluted by the idle time processing, slowing things } down for the foreground process. I play with that idea, having a task with the priority set just higher than the idle loop. It let us keep the idle loop unpolluted and allowed it to actually be nothing more than an idle loop. It was nice to be able to dynamically assign priority to PPC hash table clearing, page clearing and any other wacky idea I came up with depending on the load and need of the running system. } > Another alternative is to have an idle process rather then try to do } > things in the idle loop. This has the advantage of being instantly } > interruptable if a 'real' process becomes runnable, but the disadvantage } > of having to do a context switch (albeit a relatively cheap one). } } That would probably be the cleanest solution. Maybe the idprio mechanism } could be extended to cover this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000725114800.M15614>