Skip to contentSkip to conversation

buffermem_pages removal (5/5)

PATCH In review Christoph Hellwig 4 participants 6 messages May 21, 2002 – May 22, 2002

Subsystems (4)
Memory management VFS Page allocator MM swap
lore
Share & tools
lore

Christoph Hellwig

author
#0 lore raw

PATCH 1/1 buffermem_pages removal (5/5)

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

fs/buffer.c +0 -15
@@ -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);
 }
include/linux/swap.h +0 -4
@@ -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: */
mm/page_alloc.c +0 -5
@@ -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
#1 lore raw
Quoted 2 lines · Christoph Hellwig

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.

-

author
#2 lore raw
In reply to Christoph Hellwig
Quoted 4 lines · Andrew Morton

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

Quoted 3 lines

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*

#3 lore raw
In reply to Christoph Hellwig
Quoted 8 lines · Christoph Hellwig
Quoted 4 lines · Andrew Morton

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 :(

Quoted 3 lines

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

Quoted 2 lines

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.

Quoted 5 lines
Quoted 3 lines

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

-

#4 lore raw
Quoted 3 lines

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.

#5 lore raw
In reply to Christoph Hellwig
Quoted 6 lines · Andrew Morton
Quoted 2 lines · Christoph Hellwig

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

Signature · 1 line
Daniel