From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 05:49:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9D3816A401 for ; Thu, 29 Mar 2007 05:49:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED6B13C46E for ; Thu, 29 Mar 2007 05:49:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 5311D17383; Thu, 29 Mar 2007 05:49:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l2T5ndpR012206; Thu, 29 Mar 2007 05:49:40 GMT (envelope-from phk@critter.freebsd.dk) To: Jason Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Mar 2007 15:08:38 MST." <460AE766.6050409@frebsd.org> Date: Thu, 29 Mar 2007 05:49:39 +0000 Message-ID: <12205.1175147379@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: malloc(3) (hopefully) set for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 05:49:43 -0000 In message <460AE766.6050409@frebsd.org>, Jason Evans writes: >However, there is a downside to >managing memory in chunks: unless we use madvise(2), every page of a >chunk that is touched remains physically backed until the entire chunk >can be unmapped. Thus, even a single in-use page can cause retention of >up to 1MB of memory. This is a bit of a catch-22, since madvise(2) is >too expensive to enable by default, but if we really need it, then we >really should be using it for all applications, since paging is a >system-wide issue. The solution I have been advocating for years, is that the VM system tell us a green/yellow/red status of memory availability, and send a SIGVM to all processes when it gets worse. malloc() could hook SIGVM and act intelligently based on it, and really smart applications (a browser for instance) could hook SIGVM and ditch the cache. The actual flag color could be a free discovery, if we had a system-wide mapped page in all processes. That way, in all likelyhood, instead of starting to page out, the processes would free enough "wasted" space, that we can avoid paging out, at least for a fair bit longer. Thanks for the good work on jemalloc :-) -- 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.