All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Mel Gorman <mgorman@suse.de>
Cc: akpm@linux-foundation.org, raz ben yehuda <raziebe@gmail.com>,
	riel@redhat.com, kosaki.motohiro@jp.fujitsu.com,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, stable@kernel.org
Subject: Re: [PATCH] mm: Check if PTE is already allocated during page fault
Date: Fri, 15 Apr 2011 17:06:06 +0200	[thread overview]
Message-ID: <20110415150606.GP15707@random.random> (raw)
In-Reply-To: <20110415143916.GN15707@random.random>

On Fri, Apr 15, 2011 at 04:39:16PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 15, 2011 at 11:12:48AM +0100, Mel Gorman wrote:
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 5823698..1659574 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -3322,7 +3322,7 @@ int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> >  	 * run pte_offset_map on the pmd, if an huge pmd could
> >  	 * materialize from under us from a different thread.
> >  	 */
> > -	if (unlikely(__pte_alloc(mm, vma, pmd, address)))
> > +	if (unlikely(pmd_none(*pmd)) && __pte_alloc(mm, vma, pmd, address))

I started hacking on this and I noticed it'd be better to extend the
unlikely through the end. At first review I didn't notice the
parenthesis closure stops after pte_none and __pte_alloc is now
uncovered. I'd prefer this:

    if (unlikely(pmd_none(*pmd) && __pte_alloc(mm, vma, pmd, address)))

I mean the real unlikely thing is that we return VM_FAULT_OOM, if we
end up calling __pte_alloc or not, depends on the app. Generally it
sounds more frequent that the pte is not none, so it's not wrong, but
it's even less likely that __pte_alloc fails so that can be taken into
account too, and __pte_alloc runs still quite frequently. So either
above or:

    if (unlikely(pmd_none(*pmd)) && unlikely(__pte_alloc(mm, vma, pmd, address)))

I generally prefer unlikely only when it's 100% sure thing it's less
likely (like the VM_FAULT_OOM), so the first version I guess it's
enough (I'm afraid unlikely for pte_none too, may make gcc generate a
far away jump possibly going out of l1 icache for a case that is only
512 times less likely at best). My point is that it's certainly hugely
more unlikely that __pte_alloc fails than the pte is none.

This is a real nitpick though ;).

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: Mel Gorman <mgorman@suse.de>
Cc: akpm@linux-foundation.org, raz ben yehuda <raziebe@gmail.com>,
	riel@redhat.com, kosaki.motohiro@jp.fujitsu.com,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, stable@kernel.org
Subject: Re: [PATCH] mm: Check if PTE is already allocated during page fault
Date: Fri, 15 Apr 2011 17:06:06 +0200	[thread overview]
Message-ID: <20110415150606.GP15707@random.random> (raw)
In-Reply-To: <20110415143916.GN15707@random.random>

On Fri, Apr 15, 2011 at 04:39:16PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 15, 2011 at 11:12:48AM +0100, Mel Gorman wrote:
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 5823698..1659574 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -3322,7 +3322,7 @@ int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> >  	 * run pte_offset_map on the pmd, if an huge pmd could
> >  	 * materialize from under us from a different thread.
> >  	 */
> > -	if (unlikely(__pte_alloc(mm, vma, pmd, address)))
> > +	if (unlikely(pmd_none(*pmd)) && __pte_alloc(mm, vma, pmd, address))

I started hacking on this and I noticed it'd be better to extend the
unlikely through the end. At first review I didn't notice the
parenthesis closure stops after pte_none and __pte_alloc is now
uncovered. I'd prefer this:

    if (unlikely(pmd_none(*pmd) && __pte_alloc(mm, vma, pmd, address)))

I mean the real unlikely thing is that we return VM_FAULT_OOM, if we
end up calling __pte_alloc or not, depends on the app. Generally it
sounds more frequent that the pte is not none, so it's not wrong, but
it's even less likely that __pte_alloc fails so that can be taken into
account too, and __pte_alloc runs still quite frequently. So either
above or:

    if (unlikely(pmd_none(*pmd)) && unlikely(__pte_alloc(mm, vma, pmd, address)))

I generally prefer unlikely only when it's 100% sure thing it's less
likely (like the VM_FAULT_OOM), so the first version I guess it's
enough (I'm afraid unlikely for pte_none too, may make gcc generate a
far away jump possibly going out of l1 icache for a case that is only
512 times less likely at best). My point is that it's certainly hugely
more unlikely that __pte_alloc fails than the pte is none.

This is a real nitpick though ;).

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-04-15 15:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-15 10:12 [PATCH] mm: Check if PTE is already allocated during page fault Mel Gorman
2011-04-15 10:12 ` Mel Gorman
2011-04-15 13:23 ` Rik van Riel
2011-04-15 13:23   ` Rik van Riel
2011-04-15 14:39 ` Andrea Arcangeli
2011-04-15 14:39   ` Andrea Arcangeli
2011-04-15 15:06   ` Andrea Arcangeli [this message]
2011-04-15 15:06     ` Andrea Arcangeli
2011-04-18  7:21     ` raz ben yehuda
2011-04-18  7:21       ` raz ben yehuda
2011-04-18 10:23     ` Mel Gorman
2011-04-18 10:23       ` Mel Gorman
2011-04-21  6:59 ` Minchan Kim
2011-04-21  6:59   ` Minchan Kim
2011-04-21 11:08   ` Mel Gorman
2011-04-21 11:08     ` Mel Gorman
2011-04-21 14:26     ` Minchan Kim
2011-04-21 14:26       ` Minchan Kim
2011-04-21 16:00       ` Mel Gorman
2011-04-21 16:00         ` Mel Gorman
2011-04-21 16:14         ` Andrea Arcangeli
2011-04-21 16:14           ` Andrea Arcangeli
2011-04-22  0:54           ` Minchan Kim
2011-04-22  0:54             ` Minchan Kim
2011-04-26 13:00             ` Andrea Arcangeli
2011-04-26 13:00               ` Andrea Arcangeli
2011-04-22  1:01         ` Minchan Kim
2011-04-22  1:01           ` Minchan Kim
2011-04-27 13:50 ` Johannes Weiner
2011-04-27 13:50   ` 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=20110415150606.GP15707@random.random \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=raziebe@gmail.com \
    --cc=riel@redhat.com \
    --cc=stable@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.