Date: Tue, 8 Jan 2008 11:28:12 +1100 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Kostik Belousov <kostikbel@gmail.com>, Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-current@freebsd.org, Igor Mozolevsky <igor@hybrid-lab.co.uk> Subject: Re: sbrk(2) broken Message-ID: <20080108112812.13ffab9f@duncan.reilly.home> In-Reply-To: <15094.1199751424@critter.freebsd.dk> References: <a2b6592c0801071606g4c0dcb9ap117e345fda5e7e5f@mail.gmail.com> <15094.1199751424@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 08 Jan 2008 00:17:04 +0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: > 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. Aah, OK, so there's some essentially system-level caching going on behind the scenes, and that's readily malleable for this sort of thing. I thought that you were proposing some way to propagate the "yellow" or "red" conditions to user-program activity through malloc, which seems hard, since the only official out-of-band signal there is a zero return. I'll have to track down your papers, though, because I thought that the whole problem revolved around the fact that malloc(3) doesn't hand out physical pages at all: that was left up to the kernel vm pager to do as needed. Is it zeroed (and therefore touched/present) pages that malloc keeps a stash of? > 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 agree. That sort of auto-tuning of the space/speed trade-off would be extremely cool. > If one implements this with three states: > > Green - "all clear" > > Yellow - "tight" - free one before you allocate one if you can. > > Red - "all out" - free all that you sensibly can. I imagine that even if the accounting can be managed efficiently, the specification of the specific thresholds would be fairly tricky to specify... Cheers, -- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080108112812.13ffab9f>