From: Andrea Arcangeli <andrea@suse.de>
To: Alexander Viro <viro@math.psu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.10pre11aa1
Date: Wed, 19 Sep 2001 14:54:17 +0200 [thread overview]
Message-ID: <20010919145417.R720@athlon.random> (raw)
In-Reply-To: <Pine.GSO.4.21.0109190420510.28824-100000@weyl.math.psu.edu> <Pine.GSO.4.21.0109190800590.28824-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0109190800590.28824-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Wed, Sep 19, 2001 at 08:07:30AM -0400
On Wed, Sep 19, 2001 at 08:07:30AM -0400, Alexander Viro wrote:
> BTW, what's to stop shrink_cache() from picking a page out of ramdisk
> pagecache and calling ->writepage() on it? The thing will immediately
it's the same trick that ramfs uses also, so it is the right way as far
as ramfs isn't broken too (and quite frankly these days ramfs is much
more important than ramdisk given our heavy use of logical caches).
> If you get a lot of stuff in ramdisks, things can get rather insteresting...
under heavy memory pressure possibly, that applies to ramfs also as said
above. Anyways this was a clean approch and the new vm make sure not to
get confused by writepage marking the page dirty again, the worst thing
that can happen is some cpu cycle wasted, _but_ we save cpu cycles in
not having special checks when ramfs isn't in use and the fact there are no
special cases also make the code cleaner.
Now, I'm fine to add special cases if this sort out to be too much cpu
wasted [check how much shrink_cache show up on the profiling to be sure]
(of course not just for ramdisk that isn't very important, but for ramfs
too which is much more critical to be very efficient).
Andrea
prev parent reply other threads:[~2001-09-19 12:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010918230242.F720@athlon.random>
2001-09-19 8:49 ` 2.4.10pre11aa1 Alexander Viro
2001-09-19 12:07 ` 2.4.10pre11aa1 Alexander Viro
2001-09-19 12:54 ` Andrea Arcangeli [this message]
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=20010919145417.R720@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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