From owner-freebsd-hackers Sat Jul 22 10:39:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (backplane-inc.SanFranciscosfd.cw.net [206.24.214.242]) by hub.freebsd.org (Postfix) with ESMTP id 0C5E437C2F5 for ; Sat, 22 Jul 2000 10:39:12 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.9.3/8.9.3) id KAA31376; Sat, 22 Jul 2000 10:39:08 -0700 (PDT) (envelope-from dillon) Date: Sat, 22 Jul 2000 10:39:08 -0700 (PDT) From: Matt Dillon Message-Id: <200007221739.KAA31376@earth.backplane.com> To: Lars Eggert Cc: Alan Cox , hackers@FreeBSD.ORG, cort@cs.nmt.edu Subject: Re: clearing pages in the idle loop References: <20000719234124.H14543@cs.rice.edu> <39788E48.60F8A59F@isi.edu> <200007211906.MAA19989@earth.backplane.com> <3978A802.E05CC45@isi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Since the only effect of a cache miss is less efficient use of :> the cpu, and since the page zeroing only occurs when the cpu is idle, :> I would not expect to see much improvement from attempts to refine :> the page-zeroing operation (beyond the simple hysteresis that FreeBSD :> uses now and perhaps being able to bypass the cache). : :The reason why I'm interested in Cort's results is that I'd like to extend :processing in the idle loop to other things (see my other mail). Cort :measured a performance decrease of foreground processing, due to polluted :caches after idle-time processing. We're discussing if disabling caches :during the idle loop may prevent that. I think what you are observing may not be cache-related at all, but may simply be the fact that zeroing a page takes a minimum amount of time during which another task will not be scheduled, verses that other task being scheduled instantly if all the idle loop were doing was checking for new tasks to run. :> The real benefit occurs on a medium-to-heavily loaded machine which is :> NOT cpu bound. Since nearly all page allocations require zero'd pages, :> having a pool of pre-zero'd pages significantly reduces allocation :> latency at just the time the process doing the allocation can best :> benefit from it. In a cpu-bound system, the idle loop does not run :> as often (or at all) and no pre-zeroing occurs anyway. : :I agree. However, on a medium-to-heavily loaded CPU, you'd probably see the :largest decrease of foreground performance, as the idle times are short and :bursty, and so your caches may get polluted more frequently. (Assuming :cache pollution is in fact a problem; Allan seems to not think so.) : :If Allan still has his patches, I'll run some experiments, so we have some :numbers to talk about. Maybe it doesn't matter. 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). The FreeBSD page zeroing code in the idle loop typically does not run all that often with an interactive load because interactive loads tend not to allocate memory at a high rate, so the hysteresis points do not get hit as often. Hmm. Maybe there's a bug in the hysteresis calculation, I'll check it out. -Matt :> In regards to just zeroing the pieces of a page that need zeroing - this :> is NOT an optimization designed for the idle-loop page-zeroing code. : :I made a mistake tracing through the code. Sorry. : :But it may be interesting to speculate if this would speed things up. Would :probably require MMU support though. : :Lars :-- :Lars Eggert Information Sciences Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message