On 08/20/2013 12:45 AM, Andrew Morton wrote:
> On Mon, 19 Aug 2013 14:23:40 +0200 Vlastimil Babka <vbabka@xxxxxxx> wrote:
>
>> After introducing batching by pagevecs into munlock_vma_range(), we can further
>> improve performance by bypassing the copying into per-cpu pagevec and the
>> get_page/put_page pair associated with that. Instead we perform LRU putback
>> directly from our pagevec. However, this is possible only for single-mapped
>> pages that are evictable after munlock. Unevictable pages require rechecking
>> after putting on the unevictable list, so for those we fallback to
>> putback_lru_page(), hich handles that.
>>
>> After this patch, a 13% speedup was measured for munlocking a 56GB large memory
>> area with THP disabled.
>>
>> ...
>>
>> +static void __putback_lru_fast(struct pagevec *pvec, int pgrescued)
>> +{
>> + count_vm_events(UNEVICTABLE_PGMUNLOCKED, pagevec_count(pvec));
>> + /* This includes put_page so we don't call it explicitly */
>
> This had me confused for a sec. __pagevec_lru_add() includes put_page,
> so we don't call __pagevec_lru_add()? That's the problem with the word
> "it" - one often doesn't know what it refers to.
>
> Clarity:
>
> --- a/mm/mlock.c~mm-munlock-bypass-per-cpu-pvec-for-putback_lru_page-fix
> +++ a/mm/mlock.c
> @@ -264,7 +264,10 @@ static bool __putback_lru_fast_prepare(s
> static void __putback_lru_fast(struct pagevec *pvec, int pgrescued)
> {
> count_vm_events(UNEVICTABLE_PGMUNLOCKED, pagevec_count(pvec));
> - /* This includes put_page so we don't call it explicitly */
> + /*
> + *__pagevec_lru_add() calls release_pages() so we don't call
> + * put_page() explicitly
> + */
> __pagevec_lru_add(pvec);
> count_vm_events(UNEVICTABLE_PGRESCUED, pgrescued);
> }
Yes this is definitely better, thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>