[PATCH] buffermem_pages removal (5/5)

[PATCH] buffermem_pages removal (5/5)

[Christoph Hellwig]

No more users of buffermem_pages are left, remove it.
While at it also remove some orphaned externs around it in swap.h


--- 1.102/fs/buffer.c	Mon May 20 15:40:11 2002
+++ edited/fs/buffer.c	Tue May 21 13:55:53 2002
@@ -36,9 +36,6 @@
 
 #define BH_ENTRY(list) list_entry((list), struct buffer_head, b_assoc_buffers)
 
-/* This is used by some architectures to estimate available memory. */
-atomic_t buffermem_pages = ATOMIC_INIT(0);
-
 /*
  * Hashed waitqueue_head's for wait_on_buffer()
  */
@@ -151,10 +148,6 @@
 static inline void
 __set_page_buffers(struct page *page, struct buffer_head *head)
 {
-	struct inode *inode = page->mapping->host;
-
-	if (inode && S_ISBLK(inode->i_mode))
-		atomic_inc(&buffermem_pages);
 	if (page_has_buffers(page))
 		buffer_error();
 	set_page_buffers(page, head);
@@ -164,14 +157,6 @@
 static inline void
 __clear_page_buffers(struct page *page)
 {
-	struct address_space *mapping = page->mapping;
-
-	if (mapping) {
-		struct inode *inode = mapping->host;
-
-		if (S_ISBLK(inode->i_mode))
-			atomic_dec(&buffermem_pages);
-	}
 	clear_page_buffers(page);
 	page_cache_release(page);
 }
--- 1.43/include/linux/swap.h	Mon May 20 17:07:21 2002
+++ edited/include/linux/swap.h	Tue May 21 14:35:22 2002
@@ -102,12 +102,8 @@
 extern unsigned int nr_free_pages(void);
 extern unsigned int nr_free_buffer_pages(void);
 extern unsigned int nr_free_pagecache_pages(void);
-extern unsigned long nr_buffermem_pages(void);
 extern int nr_active_pages;
 extern int nr_inactive_pages;
-extern atomic_t nr_async_pages;
-extern atomic_t buffermem_pages;
-extern spinlock_t pagecache_lock;
 extern void __remove_inode_page(struct page *);
 
 /* Incomplete types for prototype declarations: */
--- 1.57/mm/page_alloc.c	Sun May  5 18:56:08 2002
+++ edited/mm/page_alloc.c	Tue May 21 14:27:32 2002
@@ -569,11 +569,6 @@
 }
 #endif
 
-unsigned long nr_buffermem_pages(void)
-{
-	return atomic_read(&buffermem_pages);
-}
-
 /*
  * Accumulate the page_state information across all CPUs.
  * The result is unavoidably approximate - it can change

Re: [PATCH] buffermem_pages removal (5/5)

[Andrew Morton]

Christoph Hellwig wrote:
> 
> No more users of buffermem_pages are left, remove it.

Yeah, may as well.

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.

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.

-

Re: [PATCH] buffermem_pages removal (5/5)

[Christoph Hellwig]

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?  If filesystems
access them without buffer_heads there is no reason to not put the
pages in high memory.  I also remember vaguely that you intend to move
buffer_heads to high memory in the longer term..

> 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*

Re: [PATCH] buffermem_pages removal (5/5)

[Andrew Morton]

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...

-

Re: [PATCH] buffermem_pages removal (5/5)

[Martin J. Bligh]

> 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.

Hopefully I'll have that surgery completed this week, or early
next week, assuming the per-address space kmap is sufficient
for what you're looking at.

M.

Re: [PATCH] buffermem_pages removal (5/5)

[Daniel Phillips]

On Tuesday 21 May 2002 20:27, Andrew Morton wrote:
> Christoph Hellwig wrote:
> > 
> > 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 :(

It's time to change all the bh->b_data to bh_data(bh) and b_data
to _b_data /* don't use */

-- 
Daniel