Date: Thu, 29 Mar 2007 05:49:39 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Jason Evans <jasone@frebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: malloc(3) (hopefully) set for 7.0 Message-ID: <12205.1175147379@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 28 Mar 2007 15:08:38 MST." <460AE766.6050409@frebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12205.1175147379>