From owner-freebsd-hackers Thu Mar 7 11:37:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 0D59637B404 for ; Thu, 7 Mar 2002 11:37:41 -0800 (PST) Received: from pool0314.cvx21-bradley.dialup.earthlink.net ([209.179.193.59] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16j3hd-0006Bq-00; Thu, 07 Mar 2002 11:37:25 -0800 Message-ID: <3C87C164.A97EDEF0@mindspring.com> Date: Thu, 07 Mar 2002 11:37:08 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "Rogier R. Mulhuijzen" , Mike Silbersack , Tom , Dimitar Peikov , cjp , freebsd-hackers@FreeBSD.ORG Subject: Re: Swapping performance References: <20020307095452.D18855-100000@frond.minions.com> <5.1.0.14.0.20020307193205.01c3b0f0@mail.drwilco.net> <3C87BD3D.49BE8105@mindspring.com> <200203071926.g27JQhU68778@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :The bzero is unnecessary on FreeBSD. Allocated pages start out > :zero'ed. Part of the performance issue might be that FreeBSD is > :being asked to zero the pages twice, instead of once. > > malloc() does not guarentee a zero'd page, even though the > side effect of a malloc() that large could very well be to map > demand-zero-fill space. For his particular test, all the pages come that way. > The bzero() will have the effect of force-instantiating the > storage for the malloc'd space. It's appropriate for the > test, I suppose, since the test is trying to test swap > performance. Maybe. If so, it's not really something that belongs in the time calculation, I think, unless he's testing the instantiation, rather than the swapping speed... which is what he said he was testing. > :It might be more interesting to mmap() anonymous memory > :(e.g. out of /dev/zero), rather than using malloc, and > :then use that memory the same way, instead (it's swap > :backed, as well). Giving it an madvise, to tell it your > :intended access pattern would also be useful. > > Just mmap(... MAP_ANON...). It will make no difference, > though, because that is effectively what a malloc() of > that size will do anyway. It gets all the malloc() code out of the code path, so we can tell if it's a slow malloc or a slow swap... basically, it makes it more likely he is measuring what he says he is intent on measuring. The other issue is that the bzero is definitely not needed in that case. The access pattern is actually pessimal; it avoids all of the sequential access optimizations, at the same time not disabling FreeBSD's looking for them. If the code were to mmap() and still bzero(), then it should madvise() sequential for the bzero, and then re-madvise() for the pessimal modification/access phase, so that FreeBSD didn't attempt to look for things to optimize. All in all, it's a test for the degenerate case; but I'm trying very hard not to just throw it out as a dumb thing to do, and play the game in figuring out why it's slow, and if it's really measuring swap performance, or malloc or bzero or whatever performance. Hell, part of the issue might be the use of the fprintf() paging the stdio buffer back in, when using a write() would avoid the problem entirely. ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message