From: Adrian Bunk <bunk@kernel.org>
To: Bodo Eggert <7eggert@gmx.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andreas Dilger <adilger@sun.com>,
Valdis.Kletnieks@vt.edu, David Chinner <dgc@sgi.com>,
Valerie Henson <val@vahconsulting.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger@clusterfs.com>, Ric Wheeler <ric@emc.com>
Subject: Re: [RFC] Parallelize IO for e2fsck
Date: Fri, 25 Jan 2008 01:08:09 +0200 [thread overview]
Message-ID: <20080124230809.GA29120@does.not.exist> (raw)
In-Reply-To: <E1JI5vz-0001GG-Vs@be1.7eggert.dyndns.org>
On Thu, Jan 24, 2008 at 06:32:15PM +0100, Bodo Eggert wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> >> I'd tried to advocate SIGDANGER some years ago as well, but none of
> >> the kernel maintainers were interested. It definitely makes sense
> >> to have some sort of mechanism like this. At the time I first brought
> >> it up it was in conjunction with Netscape using too much cache on some
> >> system, but it would be just as useful for all kinds of other memory-
> >> hungry applications.
> >
> > There is an early thread for a /proc file which you can add to your
> > poll() set and it will wake people when memory is low. Very elegant and
> > if async support is added it will also give you the signal variant for
> > free.
>
> IMO you'll need a userspace daemon. The kernel does only know about the
> amount of memory available / recommended for a system (or container),
> while the user knows which program's cache is most precious today.
>
> (Off cause the userspace daemon will in turn need the /proc file.)
>
> I think a single, system-wide signal is the second-to worst solution: All
> applications (or the wrong one, if you select one) would free their caches
> and start to crawl, and either stay in this state or slowly increase their
> caches again until they get signaled again. And the signal would either
> come too early or too late. The userspace daemon could collect the weighted
> demand of memory from all applications and tell them how much to use.
I don't think that's something that would require finetuning on a
per-application basis - the kernel should tell all applications once to
reduce memory consumption and write a fat warning to the logs (which
will on well-maintained systems be mailed to the admin).
Your "and tell them how much to use" wouldn't work for most applications
- e.g. I've worked the last weeks with a computer with 512 MB RAM and no
Swap, which means usually only 200 MB of free RAM. I've gotten quite
used to git aborting with "fatal: Out of memory, malloc failed" when
200 MB weren't enough for git, and I don't think there is any reasonable
way for git to reduce the memory usage while continuing to run.
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).
And from a performance point of view letting applications voluntarily
free some memory is better even than starting to swap.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2008-01-24 23:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9Mo9w-7Ws-25@gated-at.bofh.it>
[not found] ` <9Mo9w-7Ws-23@gated-at.bofh.it>
[not found] ` <9OdWm-7uN-25@gated-at.bofh.it>
[not found] ` <9Oi9A-5EJ-3@gated-at.bofh.it>
[not found] ` <9OiMg-6IC-1@gated-at.bofh.it>
[not found] ` <9OlqL-2xG-3@gated-at.bofh.it>
[not found] ` <9Orda-3ub-45@gated-at.bofh.it>
2008-01-24 17:32 ` [RFC] Parallelize IO for e2fsck Bodo Eggert
2008-01-24 22:07 ` Andreas Dilger
2008-01-24 23:08 ` Adrian Bunk [this message]
2008-01-24 23:40 ` Theodore Tso
2008-01-25 0:25 ` Zan Lynx
2008-01-25 11:09 ` Andreas Dilger
2008-01-26 0:55 ` Zan Lynx
2008-01-26 11:56 ` KOSAKI Motohiro
2008-01-26 12:32 ` KOSAKI Motohiro
2008-01-26 13:55 ` Kernel Event Notifications (was: [RFC] Parallelize IO for e2fsck) Al Boldi
2008-01-26 16:01 ` KOSAKI Motohiro
2008-01-28 23:28 ` Jon Masters
2008-02-03 13:38 ` KOSAKI Motohiro
[not found] <alpine.LSU.0.999.0801252338460.26260@be1.lrz>
2008-01-26 1:55 ` [RFC] Parallelize IO for e2fsck Bryan Henderson
2008-01-26 13:21 ` Theodore Tso
[not found] <70b6f0bf0801161322k2740a8dch6a0d6e6e112cd2d0@mail.gmail.com>
2008-01-16 21:30 ` Valerie Henson
2008-01-18 1:15 ` David Chinner
2008-01-18 1:43 ` Valerie Henson
2008-01-21 23:00 ` Andreas Dilger
2008-01-22 3:38 ` David Chinner
2008-01-22 4:17 ` Valdis.Kletnieks
2008-01-22 7:00 ` Andreas Dilger
2008-01-22 13:05 ` Alan Cox
2008-01-22 14:40 ` Theodore Tso
2008-01-22 14:57 ` Arnaldo Carvalho de Melo
2008-01-28 19:30 ` Pavel Machek
2008-01-28 19:56 ` Theodore Tso
2008-01-28 20:01 ` Pavel Machek
2008-02-03 13:51 ` KOSAKI Motohiro
2008-01-29 8:29 ` david
2008-01-22 7:05 ` Andreas Dilger
2008-01-22 8:16 ` David Chinner
2008-01-22 17:42 ` Bryan Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080124230809.GA29120@does.not.exist \
--to=bunk@kernel.org \
--cc=7eggert@gmx.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=adilger@clusterfs.com \
--cc=adilger@sun.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dgc@sgi.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ric@emc.com \
--cc=tytso@mit.edu \
--cc=val@vahconsulting.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).