lkml.org 
[lkml]   [2011]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: long sleep_on_page delays writing to slow storage
On Wed, Nov 09, 2011 at 05:52:01PM +0000, Mel Gorman wrote:
> -#define alloc_pages_vma(gfp_mask, order, vma, addr, node) \
> - alloc_pages(gfp_mask, order)
> +#define alloc_pages_vma(gfp_mask, order, vma, addr, node, drop_mmapsem) \
> + ({ \
> + if (drop_mmapsem) \
> + up_read(&vma->vm_mm->mmap_sem); \
> + alloc_pages(gfp_mask, order); \
> + })

I wouldn't change alloc_pages_vma. I think it's better to add and have
that called only by khugepaged:

alloc_pages_vma_up_read(gfp_mask, order, vma, addr, node)
{
__alloc_pages_vma(gfp_mask, order, vma, addr, node, true);
}

alloc_pages_vma(gfp_mask, order, vma, addr, node)
{
__alloc_pages_vma(gfp_mask, order, vma, addr, node, false);
}

I wonder if a change like this would be enough?

sync_migration = !(gfp_mask & __GFP_NO_KSWAPD);

But even if hidden in a new function, the main downside overall is the
fact we'll pass one more var through the stack of fast paths.

Johannes I recall you reported this too and Mel suggested the above
change, did it help in the end?

Your change in khugepaged context makes perfect sense anyway, just we
should be sure it's really needed before adding more variables in fast
path I think.


\
 
 \ /
  Last update: 2011-11-09 19:09    [W:0.075 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site