From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 00:57:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F52016A419 for ; Tue, 8 Jan 2008 00:57:23 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id AD1C813C459 for ; Tue, 8 Jan 2008 00:57:22 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so4409003uge.37 for ; Mon, 07 Jan 2008 16:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ueq/Gw7VkaqBMwcYyNyWP3/sAeMZRE8mYFnHPCRhL1o=; b=gon4cqHJeZRsRMIh+UDNV34JUUSECNTejehwFZn46Jw6cyGe/tiSAQ0/ndxEQZB3T1Pd1TpF8xlDdMC+SyoAn0V8H4DBagtUBbqrM4geyMxY1wfECXKoygczQb5SMTxxP221fK05DFCQIVmW/MyR+4iaGra8WIz4JwS2Z7tm/hI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=F2jqQkDBOpNOmMmad1XEh/GapRNU7QaYZDPrjz1ofIMXiHC410W4j9iewqJbwoC/3NyMqL2+V268ophcqvTNcZxJI5YrtxFzgWSxh/BbJ2oiMT2jwfScP55Pjn+Dg8wc7MGmLX3BQFKQeyWndVVplrHIK2PpjJRK4NY5+JjaVe0= Received: by 10.66.236.13 with SMTP id j13mr93177ugh.30.1199753841373; Mon, 07 Jan 2008 16:57:21 -0800 (PST) Received: by 10.66.248.11 with HTTP; Mon, 7 Jan 2008 16:57:21 -0800 (PST) Message-ID: Date: Tue, 8 Jan 2008 00:57:21 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <15094.1199751424@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <15094.1199751424@critter.freebsd.dk> X-Google-Sender-Auth: 098994f64434a7c2 Cc: Kostik Belousov , Andrew Reilly , freebsd-current@freebsd.org, Peter Jeremy Subject: Re: sbrk(2) broken 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: Tue, 08 Jan 2008 00:57:23 -0000 On 08/01/2008, Poul-Henning Kamp wrote: > In message , "Igor > Mozolevsky" writes: > >On 07/01/2008, Andrew Reilly wrote: > >> On Mon, 07 Jan 2008 13:18:47 +0000 > >> "Poul-Henning Kamp" wrote: > >> > >> > Yes, but you will not see this complication, it will be hidden > >> > in the implementation of malloc(3). > >> > >> How could you hide it inside malloc? Would malloc start > >> returning 0 after receiving the "less mem than desirable" > >> signal? Would it ever go back to returning non-zero? > > > >I'm with Andrew on this one. The only (sensible) way I could see it > >being hidden behind malloc() is if malloc() blocks until sufficient > >memory becomes available. > > You should read some recent literature on malloc(3), my own and > Jasons papers are good places to start. Can you provide some refs/links, unfortunately googling for PKH+malloc() is pretty futile! > For performance reasons, malloc(3) will hold on to a number of pages > that theoretically could be given back to the kernel, simply because > it expects to need them shortly. > > Such parameters and many others of the malloc implementation can > be tweaked to "waste" more or less memory, in response to a sensibly > granular indication from the kernel about how bad things are. > > Also, many subsystems in the kernel could adjust their memory use > in response to a "memory pressure" indication, if memory is tight, > we could cache vnodes and inodes less agressively, if things are > going truly bad, we can even ditch all non-active entries from > these caches. I don't think it's the kernel that is being ill-mannered (unless, of course, it's running ZFS ;-)) by eating up the memory, it's the user processes that consume most resources. > Nothing prevents an intelligent process from listening in and > doing sensible things, firefox could ditch the memory cache of > pages for instance. How do you propose they 'eavesdrop' on the kernel? Baring in mind that most apps nowadays are written for Linux and are hacked to be portable afterwards (just look at the number of patches in the ports tree), it's much simpler to write a signal handler than FreeBSD-kernel specific listening code... > But we can't get anywhere until some VM wizard produces the > three "lamps" for us to look at in the first place, that's where > we have been stuck for the last 10 years. I think the problem is not in providing the lamps to indicate the state, but figuring out an algorithm for judging green->yellow and yellow->green transitions... Igor