From: Bryan Henderson <hbryan@us.ibm.com>
To: David Chinner <dgc@sgi.com>
Cc: Andreas Dilger <adilger@clusterfs.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Ric Wheeler <ric@emc.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Valerie Henson <val@vahconsulting.com>
Subject: Re: [RFC] Parallelize IO for e2fsck
Date: Tue, 22 Jan 2008 09:42:45 -0800 [thread overview]
Message-ID: <OFCCC72BE7.3EF7DC79-ON882573D8.00601CEE-882573D8.00614CFA@us.ibm.com> (raw)
In-Reply-To: <20080122033830.GR155259@sgi.com>
>I think there is a clear need for applications to be able to
>register a callback from the kernel to indicate that the machine as
>a whole is running out of memory and that the application should
>trim it's caches to reduce memory utilisation.
>
>Perhaps instead of swapping immediately, a SIGLOWMEM could be sent ...
The problem with that approach is that the Fsck process doesn't know how
its need for memory compares with other process' need for memory. How
much memory should it give up? Maybe it should just quit altogether if
other processes are in danger of deadlocking. Or maybe it's best for it
to keep all its memory and let some other frivolous process give up its
memory instead.
It's the OS's job to have a view of the entire system and make resource
allocation decisions.
If it's just a matter of the application choosing a better page frame to
vacate than what the kernel would have taken, (which is more a matter of
self-interest than resource allocation), then Fsck can do that more
directly by just monitoring its own page fault rate. If it's high, then
it's using more real memory than the kernel thinks it's entitled to and it
can reduce its memory footprint to improve its speed. It can even check
whether an access to readahead data caused a page fault; if so, it knows
reading ahead is actually making things worse and therefore reduce
readahead until the page faults stop happening.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
next prev parent reply other threads:[~2008-01-22 17:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <70b6f0bf0801161322k2740a8dch6a0d6e6e112cd2d0@mail.gmail.com>
2008-01-16 21:30 ` [RFC] Parallelize IO for e2fsck 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 [this message]
[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 ` Bodo Eggert
2008-01-24 22:07 ` Andreas Dilger
2008-01-24 23:08 ` Adrian Bunk
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
[not found] <alpine.LSU.0.999.0801252338460.26260@be1.lrz>
2008-01-26 1:55 ` Bryan Henderson
2008-01-26 13:21 ` Theodore Tso
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=OFCCC72BE7.3EF7DC79-ON882573D8.00601CEE-882573D8.00614CFA@us.ibm.com \
--to=hbryan@us.ibm.com \
--cc=adilger@clusterfs.com \
--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).