Re: [PATCH 8/8] Mark page cache pages as __GFP_PAGECACHE instead of __GFP_MOVABLE

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

On Tue, 15 May 2007, Christoph Lameter wrote:

> On Tue, 15 May 2007, Mel Gorman wrote:
>
>> On Tue, 15 May 2007, Christoph Lameter wrote:
>>
>>> On Tue, 15 May 2007, Mel Gorman wrote:
>>>
>>>> Currently page cache pages are grouped with MOVABLE allocations. This
>>>> appears
>>>> to work well in practice as page cache pages are usually reclaimable via
>>>> the LRU. However, this is not strictly correct as page cache pages can
>>>> only
>>>> be cleaned and discarded, not migrated. During readahead, pages may also
>>>> exist on a pool for a period of time instead of on the LRU giving them a
>>>> differnet lifecycle to ordinary movable pages.
>>>
>>> Sorry but pagecache pages can be migrated.
>>>
>>
>> Poor phrasing prehaps. I was under the impression that page migration was only
>> concerned with pages mapped by process page tables for the move_pages() call.
>> The statement above was also referring to pages read by readahead and normal
>> file IO. I'm pretty sure they could be migrated without difficulty though once
>> the source pages are identified. Either way, the separate grouping of page
>> cache is probably not worthwhile for the moment.
>
> So page cache = unmapped I/O pages?

Unmapped IO pages as well as the mapped pages. As far as grouping pages by 
mobility is concerned, it is difficult to tell the difference at the time 
of allocation without excessive use of __GFP flags. The grouping is 
probably not worthwhile but for clarity, the use GFP_*_PAGECACHE is. Using 
__GFP_PAGECACHE to clear up __page_cache_alloc() is worth looking at but 
I'm not sure the cost of a __GFP_ flag is justified

> These can also be migrated. They still
> carry a refcount of the radix tree and page migration will have to update
> that pointer.
>
> Page migration in its current form is indeed only used to move mapped
> pages but that is incidental to the current usage patterns. It is intended
> to be a generic page migration framework.
>

Perfect. That matches my current understanding.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>