From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 17:13:53 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 0C0C7337 for ; Fri, 12 Oct 2012 17:13:53 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B5C408FC12 for ; Fri, 12 Oct 2012 17:13:51 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7AA3E3B080; Fri, 12 Oct 2012 17:13:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9CHDfrQ004836; Fri, 12 Oct 2012 17:13:41 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar Subject: Re: Behavior of madvise(MADV_FREE) In-reply-to: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> From: "Poul-Henning Kamp" References: <9FEBC10C-C453-41BE-8829-34E830585E90@xcllnt.net> Date: Fri, 12 Oct 2012 17:13:41 +0000 Message-ID: <4835.1350062021@critter.freebsd.dk> Cc: Tim LaBerge , Alan Cox , "freebsd-arch@freebsd.org Arch" 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 17:13:53 -0000 -------- 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.) 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. 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. 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. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.