linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Jan Kara <jack@suse.cz>, Andy Isaacson <adi@hexapodia.org>,
	linux-kernel@vger.kernel.org, linux-mm@vger.kernel.org,
	Johannes Weiner <jweiner@redhat.com>
Subject: Re: long sleep_on_page delays writing to slow storage
Date: Wed, 9 Nov 2011 19:06:46 +0100	[thread overview]
Message-ID: <20111109180646.GM5075@redhat.com> (raw)
In-Reply-To: <20111109175201.GB3083@suse.de>

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.

  reply	other threads:[~2011-11-09 18:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07  4:59 long sleep_on_page delays writing to slow storage Andy Isaacson
2011-11-09 17:00 ` Jan Kara
2011-11-09 17:52   ` Mel Gorman
2011-11-09 18:06     ` Andrea Arcangeli [this message]
2011-11-10  0:53       ` Mel Gorman
2011-11-10  1:54         ` Andrea Arcangeli
2011-11-10  9:34       ` Johannes Weiner
2011-11-14 18:47         ` Dave Jones
2011-11-15 10:13           ` Mel Gorman
2011-11-17 19:47             ` Dave Jones
2011-11-17 22:53               ` Andrea Arcangeli
2011-11-18 11:11               ` Mel Gorman
2011-11-18 12:19                 ` Josh Boyer
2011-11-21  9:18               ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111109180646.GM5075@redhat.com \
    --to=aarcange@redhat.com \
    --cc=adi@hexapodia.org \
    --cc=jack@suse.cz \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=mgorman@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).