On Wed, 10 Aug 2005, Andrew Morton wrote: > Mel Gorman <[EMAIL PROTECTED]> wrote: > > > > On Wed, 10 Aug 2005, Andrew Morton wrote: > > > > > Mel Gorman <[EMAIL PROTECTED]> wrote: > > > > > > > > On Mon, 8 Aug 2005, Andrew Morton wrote: > > > > > > > > > Mel Gorman <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
