Re: How to reclaim inode pages on demand

[Mel Gorman <mel@csn.ul.ie>]

On Wed, 10 Aug 2005, Andrew Morton wrote:

> Mel Gorman <mel@csn.ul.ie> wrote:
> >
> > On Wed, 10 Aug 2005, Andrew Morton wrote:
> >
> > > Mel Gorman <mel@csn.ul.ie> wrote:
> > > >
> > > > On Mon, 8 Aug 2005, Andrew Morton wrote:
> > > >
> > > > > Mel Gorman <mel@csn.ul.ie> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am working on a direct reclaim strategy to free up large blocks of
> > > > > > contiguous pages. The part I have is working fine, but I am finding a
> > > > > > hundreds of pages that are being used for inodes that I need to reclaim. I
> > > > > > tried purging the inode lists using a variation of prune_icache() but it
> > > > > > is not working out.
> > > > > >
> > > > > > Given a struct page, that one knows is an inode, can anyone suggest the
> > > > > > best way to find the inode using it and free it?
> > > > >
> > > > > Simple answer: invalidate_mapping_pages(page->mapping, start, end).
> > > > >
> > > >
> > > > The majority of pages I am seeing no longer have page->mapping set. Does
> > > > this mean they are in the process of being cleared up?
> > >
> > > They're just anonymous pages, aren't they?  But you said "pages that are
> > > being used for inodes".  Confused.
> > >
> >
> > So am I, I'm missing something really stupid.
> >
> > What I have is the following;
> >
> > 1. Add a new flag GFP_INODE to mark inode pages
> > 2. Add a GFP_INODE to the flags passed to mapping_set_gfp_mask() in
> >    fs/inode.c#alloc_inode(). This means that the page allocator will now
> >    know when it is allocating pages for inodes
> > 3. Added a PG_inode flag for page->flags which will flag all pages that
> >    were allocated for inodes
> >
> > (Note, I don't intend to use this flags in the long term, I've added them
> > for investigation purposes).
> >
> > I later linearly scan the mem_map looking for pages that can be freed up
> > (usually LRU pages). I was expecting any page with PG_inode set to have a
> > page->mapping but not all of them do. It is the pages without a ->mapping
> > that are confusing the hell out of me.
>
> Well there are conditions in which mmapped file pages can get converted to
> anonymous pages due to truncate(), but I have a feeling that we stopped
> that from happening.
>

Does that also apply to when a file is unlinked rather than truncated? As
the load is a lot of kernel compiles, there are a lot of files being
created and deleted shortly afterwards.

> Also there are situations in which truncate of a still-committing ext3
> pagecache page can cause the page to remain ont he page LRUs - it's been
> truncated from the file, but ext4 still has a hold of it for journalling
> purposes.
>

In case it is journalling-related, I am going to rerun the tests on an
ext2 filesystem over the weekend.

> You cold lock the pages then check ->mapping.
>

Will do.

-- 
Mel Gorman
Part-time Phd Student                          Java Applications Developer
University of Limerick                         IBM Dublin Software Lab