From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 18:23:33 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC3FF472 for ; Fri, 12 Oct 2012 18:23:32 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id AA7BE8FC0A for ; Fri, 12 Oct 2012 18:23:32 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 23F6D4C0275; Fri, 12 Oct 2012 13:23:32 -0500 (CDT) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 2262B4C0238; Fri, 12 Oct 2012 13:23:32 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id I4Mk7HQUInoc; Fri, 12 Oct 2012 13:23:32 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id A39EF4C021B; Fri, 12 Oct 2012 13:23:31 -0500 (CDT) Message-ID: <50786023.1000206@rice.edu> Date: Fri, 12 Oct 2012 13:23:31 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: Behavior of madvise(MADV_FREE) References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> <4835.1350062021@critter.freebsd.dk> In-Reply-To: <4835.1350062021@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim LaBerge , "freebsd-arch@freebsd.org Arch" , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:23:33 -0000 On 10/12/2012 12:13, Poul-Henning Kamp wrote: > -------- > In message<9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net>, Marcel Moolenaar writes: > >> Now on to the questions: >> 1. madvise(MADV_FREE) marks the pages as clean and moves >> them to the inactive queue. > You can blame me for MADV_FREE, I nagged dyson into adding it for > phkmalloc back when 16meg RAM cost a fortune. > > The main point of MADV_FREE when was to prevent a page-out of a > dirty page, when the actual bits in the page were discarded from > the applications point of view. > > The idea was for it to be a very fast operation, which would > (potentially) save two disk operations, and the implementation > simply washed the dirty bits away. > > (I think a later modification added further VM-wizardry to retain > the allocated paging area, while avoiding the page-in in the case > the pages were stolen.) It would be more accurate to say that no action is taken to reclaim any previously allocated swap space, which is unlikely to exist anyway. > The mapping were left alone, because it was estimated and measured > that there were a high frequency of mapping reuse, in particular > in the WorldStone where multiple passes of GCC competed for physical > memory. The reference bit were left alone to not disturb the > perceived/ measured VM-footprint of the process. This last "bit" is dated. :-) We have long cleared the reference bit. > I seem to recall that we experimented with a more aggressive > version which severed the mapping and sent the page to pre-zeroing > but the benchmarks showed too much overhead in the common case > and too little gain in the relevant scenario. > > The name was clearly a mistake, but MADV_CLEAN would have been > worse, and none of us had any other ideas at the time. Today I > would have called it MADV_GARBAGE or MADV_RECYCLE. > > Given that paging anonymous pages to disk is not a major activity > and unlikely to ever become a performance bottleneck again, it may > make good sense to let MADV_FREE make the pages more appetizing > for the rest of the system. Given the way that madvise(MADV_FREE) is still used by malloc()/free(), any additional overhead would still be a pessimization most of the time. Over the years, I think you and I have both said that what we really need is the ability for the kernel to deliver an event to malloc()/free() when memory is trending toward scarcity. Applications could also use this to reduce the size of their internal caches. > But all things considered, I would advocate implementing MADV_RECYCLE > for that, we need more nuance and expressability in madvice(2) and > MADV_RECYCLE would be a good addition in its own right. Probably so. Alan