From owner-freebsd-hackers Fri Jul 21 10:54:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 01BA037B9CC for ; Fri, 21 Jul 2000 10:54:18 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA16405; Fri, 21 Jul 2000 10:54:16 -0700 (PDT) Message-ID: <39788E48.60F8A59F@isi.edu> Date: Fri, 21 Jul 2000 10:54:16 -0700 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RC i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Alan Cox Cc: hackers@freebsd.org, cort@cs.nmt.edu Subject: Re: clearing pages in the idle loop References: <20000719234124.H14543@cs.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Cort, the reason I'm CCing you is that I'm interested in using some of the mechanism described in your OSDI'99 paper for FreeBSD, and I've some questions about your Linux implementation, see below.) 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 > color at a time. That way, the cache lines replaced by > the second page you clear are the cache lines holding > the first page you cleared, and so on for the third, > fourth, ... pages cleared. Again, I saw no measurable > effect on tests like "buildworld", which is a similar > workload to the paper's if I recall correctly. Do you still have those FreeBSD patches, Alan? I'd be interested in doing some more experiments with that code. > 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?) * cache size differences between PPC and i386? I'm looking at Cort's code (arch/ppc/kernel/idle.c), and while he turns off the caching for pages he zeroes, I don't see him disabling the L1/2 caches explicitly. Is this implicit with setting the non-cacheable flag on the PPC? Also, idle-time zeroing is commented out in the version I'm looking at (1.68, 1999/10/15), where problems found after the paper was published? Lars -- Lars Eggert 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