Re: [Fwd: invalidate_inode_pages in 2.3.35]

From: Ananth Ananthanarayanan (ananth@sgi.com)
Date: Wed Jan 12 2000 - 19:33:42 EST


Andrea Arcangeli wrote:
>
> On Wed, 12 Jan 2000, Ananth Ananthanarayanan wrote:
>
> >I'm trying to measure the performance of ext2 read
> >when the read has to actually hit the device.
> >I've set up a little system call, which takes
> >the fd and invalidates the pages associated with
> >that fd from the buffer/page cache. Basically,
> >the system call does:
> >
> > filp = fget(fd);
> > invalidate_inode_pages(filp->f_dentry->d_inode);
> >
> >The above seems to do the right thing in that
> >a read on that fd goes to the disk. But, the
> >amount of free memory goes down drastically,
> >as reported by vmstat ... in fact after a few
> >runs of the test, the system starts swapping.
>
> Because the page gets not really freed if it had buffers queued on it.
>
> invalidate_inode_pages only has to be called by filesystems that can't
> generate dirty data and so that can't overlap buffer on the page cache.
>
> Andrea

Thanks for pointing out the reason for the extra reference.
Here's my present understanding of page->count (on file I/O is):

* one reference for the page being allocated ( != free)
* one reference for the page being associated with I/O
  (has bufferheads associated with it)
* one reference for being in the page cache.

The first reference is immediately dropped after its use
in generic_file_read(), after the data has been copied to user.
The last reference can be dropped by invalidate_inode_pages(),
which leaves one reference (for the buffers) as you point out.

Now truncate_inode_pages() removes the buffers associated with
a page (through block_flushpage()), so if i use
truncate_inode_pages(inode, 0) will that remove the page
from the page cache, remove the buffers & free the page to
the system wide free pool?

regards,

ananth.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:21 EST