Re: [RFC]pagealloc: compensate a task for direct page reclaim

[Minchan Kim <minchan.kim@gmail.com>]

On Fri, Sep 17, 2010 at 11:34 AM, Shaohua Li <shaohua.li@intel.com> wrote:
> On Thu, Sep 16, 2010 at 11:00:10PM +0800, Minchan Kim wrote:
>> On Thu, Sep 16, 2010 at 07:26:36PM +0800, Shaohua Li wrote:
>> > A task enters into direct page reclaim, free some memory. But sometimes
>> > the task can't get a free page after direct page reclaim because
>> > other tasks take them (this is quite common in a multi-task workload
>> > in my test). This behavior will bring extra latency to the task and is
>> > unfair. Since the task already gets penalty, we'd better give it a compensation.
>> > If a task frees some pages from direct page reclaim, we cache one freed page,
>> > and the task will get it soon. We only consider order 0 allocation, because
>> > it's hard to cache order > 0 page.
>> >
>> > Below is a trace output when a task frees some pages in try_to_free_pages(), but
>> > get_page_from_freelist() can't get a page in direct page reclaim.
>> >
>> > <...>-809   [004]   730.218991: __alloc_pages_nodemask: progress 147, order 0, pid 809, comm mmap_test
>> > <...>-806   [001]   730.237969: __alloc_pages_nodemask: progress 147, order 0, pid 806, comm mmap_test
>> > <...>-810   [005]   730.237971: __alloc_pages_nodemask: progress 147, order 0, pid 810, comm mmap_test
>> > <...>-809   [004]   730.237972: __alloc_pages_nodemask: progress 147, order 0, pid 809, comm mmap_test
>> > <...>-811   [006]   730.241409: __alloc_pages_nodemask: progress 147, order 0, pid 811, comm mmap_test
>> > <...>-809   [004]   730.241412: __alloc_pages_nodemask: progress 147, order 0, pid 809, comm mmap_test
>> > <...>-812   [007]   730.241435: __alloc_pages_nodemask: progress 147, order 0, pid 812, comm mmap_test
>> > <...>-809   [004]   730.245036: __alloc_pages_nodemask: progress 147, order 0, pid 809, comm mmap_test
>> > <...>-809   [004]   730.260360: __alloc_pages_nodemask: progress 147, order 0, pid 809, comm mmap_test
>> > <...>-805   [000]   730.260362: __alloc_pages_nodemask: progress 147, order 0, pid 805, comm mmap_test
>> > <...>-811   [006]   730.263877: __alloc_pages_nodemask: progress 147, order 0, pid 811, comm mmap_test
>> >
>>
>> The idea is good.
>>
>> I think we need to reserve at least one page for direct reclaimer who make the effort so that
>> it can reduce latency of stalled process.
>>
>> But I don't like this implementation.
>>
>> 1. It selects random page of reclaimed pages as cached page.
>> This doesn't consider requestor's migratetype so that it causes fragment problem in future.
> maybe we can limit the migratetype to MIGRATE_MOVABLE, which is the most common case.
>
>> 2. It skips buddy allocator. It means we lost coalescence chance so that fragement problem
>> would be severe than old.
> we only cache order 0 allocation, which doesn't enter lumpy reclaim, so this sounds not
> an issue to me.

I mean following as.

Old behavior.

1) return 0-order page
2) Fortunately, It fills the hole for order-1, so the page would be
promoted order-1 page
3) Fortunately, It fills the hole for order-2, so the page would be
promoted order-2 page
4) repeatedly until some order.
5) Finally, alloc_page will allocate a order-o one page(ie not
coalesce) of all which reclaimed direct reclaimer from buddy.

But your patch lost the chance on cached page.

Of course, If any pages reclaimed isn't in order 0 list(ie, all page
should be coalesce), big page have to be break with order-0 page. But
it's unlikely.

-- 
Kind regards,
Minchan Kim

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