[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1201220742.7557.10.camel@localhost>
Date: Thu, 24 Jan 2008 17:25:42 -0700
From: Zan Lynx <zlynx@....org>
To: Theodore Tso <tytso@....EDU>
Cc: Adrian Bunk <bunk@...nel.org>, Bodo Eggert <7eggert@....de>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Andreas Dilger <adilger@....com>, Valdis.Kletnieks@...edu,
David Chinner <dgc@....com>,
Valerie Henson <val@...consulting.com>,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-kernel@...r.kernel.org,
Andreas Dilger <adilger@...sterfs.com>,
Ric Wheeler <ric@....com>
Subject: Re: [RFC] Parallelize IO for e2fsck
On Thu, 2008-01-24 at 18:40 -0500, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> > In practice, there is a small number of programs that are both the
> > common memory hogs and should be able to reduce their memory consumption
> > by 10% or 20% without big problems when requested (e.g. Java VMs,
> > Firefox and databases come into my mind).
>
> I agree, it's only a few processes where this makes sense. But for
> those that do, it would be useful if they could register with the
> kernel that would like to know, (just before the system starts
> ejecting cached data, just before swapping, etc.) and at what
> frequency. And presumably, if the kernel notices that a process is
> responding to such requests with memory actually getting released back
> to the system, that process could get "rewarded" by having the OOM
> killer less likely to target that particular thread.
Have y'all been following the /dev/mem_notify patches?
http://article.gmane.org/gmane.linux.kernel/628653
--
Zan Lynx <zlynx@....org>
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists