Date: Fri, 21 Jul 2000 12:44:02 -0700 From: Lars Eggert <larse@ISI.EDU> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alan Cox <alc@cs.rice.edu>, hackers@FreeBSD.ORG, cort@cs.nmt.edu Subject: Re: clearing pages in the idle loop Message-ID: <3978A802.E05CC45@isi.edu> References: <20000719234124.H14543@cs.rice.edu> <39788E48.60F8A59F@isi.edu> <200007211906.MAA19989@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > > :Alan Cox wrote: > :> Last year, I tried to reproduce some of the claims/results > :> in this paper on FreeBSD/x86 and couldn't. I also tried > :> limiting the idle loop to clearing pages of one particular > :... > : > :> Finally, it's possible that having these pre-zeroed pages > :> in your L2 cache might be beneficial if they get allocated > :> and used right away. FreeBSD's idle loop zeroes the pages > :> that are next in line for allocation. > : > :That makes sense. Other factors that may have an impact: > : > : * if you always have enough zeroed pages remaining over your > : benchmark (> ~1/2 free pages), FreeBSD will never do the > : idle-time zeroing > : > : * it looks to me as if Cort's Linux code will always zero whole > : pages, while the FreeBSD code is a little smarter and only zeroes > : used regions of a page (less impact on caches?) > : > 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. > 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. > 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 http://www.isi.edu/larse/ University of Southern California 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?3978A802.E05CC45>