All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] buffermem_pages removal (5/5)
Date: Tue, 21 May 2002 11:27:31 -0700	[thread overview]
Message-ID: <3CEA9193.10F45174@zip.com.au> (raw)
In-Reply-To: <20020521141015.E15796@infradead.org> <3CEA8917.7A52176C@zip.com.au> <20020521185340.A694@infradead.org>

Christoph Hellwig wrote:
> 
> On Tue, May 21, 2002 at 10:51:19AM -0700, Andrew Morton wrote:
> > The buffermem_pages accounting is vaguely interesting because
> > it tells us how much of ZONE_NORMAL is being usefully used for
> > blockdev pagecache.  And ZONE_NORMAL utilisation is a bit of a
> > hot topic at present.
> 
> Yho sais all blockdev mapping have to stay ZONE_NORMAL?

Three trillion filesystems for which we don't have a mkfs which
access bh->b_data all over the place :(

>  If filesystems
> access them without buffer_heads there is no reason to not put the
> pages in high memory. 

They'd create a separate address_space in that case.  The blockdev
mappings are pretty unambiguously tied to ZONE_NORMAL in bdget().

> I also remember vaguely that you intend to move
> buffer_heads to high memory in the longer term..

s/buffer_heads/blockdev pages/

Yes, vaguely.  Haven't thought about it a lot.  I suspect the
present kmap() infrastructure would collapse under the load,
so surgery there would be needed first.
 
> > But the same information can be obtained on-demand by running
> > around the bdev superblock's inodes adding up nr_pages.  That
> > approach is better than the per-page atomic ops in buffer.c.
> 
> *nod*

In which case one could trivially report the number of active pages
against all superblocks.  Let's park this one until a need
is demonstrated though...

-

  reply	other threads:[~2002-05-21 18:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-21 13:10 [PATCH] buffermem_pages removal (5/5) Christoph Hellwig
2002-05-21 17:51 ` Andrew Morton
2002-05-21 17:53   ` Christoph Hellwig
2002-05-21 18:27     ` Andrew Morton [this message]
2002-05-21 21:54       ` Martin J. Bligh
2002-05-22  3:53       ` Daniel Phillips

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=3CEA9193.10F45174@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.