Date: Sat, 22 Jul 2000 10:39:08 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Lars Eggert <larse@ISI.EDU> Cc: Alan Cox <alc@cs.rice.edu>, hackers@FreeBSD.ORG, cort@cs.nmt.edu Subject: Re: clearing pages in the idle loop Message-ID: <200007221739.KAA31376@earth.backplane.com> References: <20000719234124.H14543@cs.rice.edu> <39788E48.60F8A59F@isi.edu> <200007211906.MAA19989@earth.backplane.com> <3978A802.E05CC45@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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 <larse@isi.edu> Information Sciences Institute
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?200007221739.KAA31376>