linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Linux-MM <linux-mm@kvack.org>,
	Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>, Jan Kara <jack@suse.cz>,
	Michal Hocko <mhocko@suse.cz>, Hugh Dickins <hughd@google.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 15/17] mm: Do not use unnecessary atomic operations when adding pages to the LRU
Date: Tue, 6 May 2014 16:55:00 +0100	[thread overview]
Message-ID: <20140506155500.GA23991@suse.de> (raw)
In-Reply-To: <5369002D.7030600@suse.cz>

On Tue, May 06, 2014 at 05:30:53PM +0200, Vlastimil Babka wrote:
> On 05/01/2014 10:44 AM, Mel Gorman wrote:
> >When adding pages to the LRU we clear the active bit unconditionally. As the
> >page could be reachable from other paths we cannot use unlocked operations
> >without risk of corruption such as a parallel mark_page_accessed. This
> >patch test if is necessary to clear the atomic flag before using an atomic
> 
>                                           active
> 

Thanks. Clearly I had atomic on the brain.

> >operation. In the unlikely even this races with mark_page_accesssed the
> >consequences are simply that the page may be promoted to the active list
> >that might have been left on the inactive list before the patch. This is
> >a marginal consequence.
> 
> Well if this is racy, then even before the patch, mark_page_accessed
> might have come right after ClearPageActive(page) anyway?
> Or is the
> changelog saying that this change only extended the race window that
> already existed? If yes it could be more explicit, as now it might
> sound as if the race was introduced.
> 

When adding pages to the LRU we clear the active bit unconditionally. As the
page could be reachable from other paths we cannot use unlocked operations
without risk of corruption such as a parallel mark_page_accessed. This
patch tests if is necessary to clear the active flag before using an atomic
operation. This potentially opens a tiny race when PageActive is checked
as mark_page_accessed could be called after PageActive was checked. The
race already exists but this patch changes it slightly. The consequence
is that that the page may be promoted to the active list that might have
been left on the inactive list before the patch. It's too tiny a race and
too marginal a consequence to always use atomic operations for.

?

-- 
Mel Gorman
SUSE Labs

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

  reply	other threads:[~2014-05-06 15:55 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01  8:44 [PATCH 00/17] Misc page alloc, shmem, mark_page_accessed and page_waitqueue optimisations Mel Gorman
2014-05-01  8:44 ` [PATCH 01/17] mm: page_alloc: Do not update zlc unless the zlc is active Mel Gorman
2014-05-01 13:25   ` Johannes Weiner
2014-05-06 15:04   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 02/17] mm: page_alloc: Do not treat a zone that cannot be used for dirty pages as "full" Mel Gorman
2014-05-06 15:09   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 03/17] mm: page_alloc: Use jump labels to avoid checking number_of_cpusets Mel Gorman
2014-05-06 15:10   ` Rik van Riel
2014-05-06 20:23   ` Peter Zijlstra
2014-05-06 22:21     ` Mel Gorman
2014-05-07  9:04       ` Peter Zijlstra
2014-05-07  9:43         ` Mel Gorman
2014-05-01  8:44 ` [PATCH 04/17] mm: page_alloc: Calculate classzone_idx once from the zonelist ref Mel Gorman
2014-05-06 16:01   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 05/17] mm: page_alloc: Only check the zone id check if pages are buddies Mel Gorman
2014-05-06 16:48   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 06/17] mm: page_alloc: Only check the alloc flags and gfp_mask for dirty once Mel Gorman
2014-05-06 17:24   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 07/17] mm: page_alloc: Take the ALLOC_NO_WATERMARK check out of the fast path Mel Gorman
2014-05-06 17:25   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 08/17] mm: page_alloc: Use word-based accesses for get/set pageblock bitmaps Mel Gorman
2014-05-02 22:34   ` Sasha Levin
2014-05-04 13:14     ` Mel Gorman
2014-05-05 12:40       ` Vlastimil Babka
2014-05-06  9:13         ` Mel Gorman
2014-05-06 14:42           ` Vlastimil Babka
2014-05-06 15:12             ` Mel Gorman
2014-05-06 20:34   ` Peter Zijlstra
2014-05-06 22:24     ` Mel Gorman
2014-05-01  8:44 ` [PATCH 09/17] mm: page_alloc: Reduce number of times page_to_pfn is called Mel Gorman
2014-05-06 18:47   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 10/17] mm: page_alloc: Lookup pageblock migratetype with IRQs enabled during free Mel Gorman
2014-05-06 18:48   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 11/17] mm: page_alloc: Use unsigned int for order in more places Mel Gorman
2014-05-01 14:35   ` Dave Hansen
2014-05-01 15:11     ` Mel Gorman
2014-05-01 15:38       ` Dave Hansen
2014-05-06 18:49   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 12/17] mm: page_alloc: Convert hot/cold parameter and immediate callers to bool Mel Gorman
2014-05-06 18:49   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 13/17] mm: shmem: Avoid atomic operation during shmem_getpage_gfp Mel Gorman
2014-05-06 18:53   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 14/17] mm: Do not use atomic operations when releasing pages Mel Gorman
2014-05-01 13:29   ` Johannes Weiner
2014-05-01 13:39     ` Mel Gorman
2014-05-01 13:47       ` Johannes Weiner
2014-05-06 18:54   ` Rik van Riel
2014-05-01  8:44 ` [PATCH 15/17] mm: Do not use unnecessary atomic operations when adding pages to the LRU Mel Gorman
2014-05-01 13:33   ` Johannes Weiner
2014-05-01 13:40     ` Mel Gorman
2014-05-06 15:30   ` Vlastimil Babka
2014-05-06 15:55     ` Mel Gorman [this message]
2014-05-01  8:44 ` [PATCH 16/17] mm: Non-atomically mark page accessed during page cache allocation where possible Mel Gorman
2014-05-01  8:44 ` [PATCH 17/17] mm: filemap: Avoid unnecessary barries and waitqueue lookup in unlock_page fastpath Mel Gorman
2014-05-05 10:50   ` Jan Kara
2014-05-07  9:03     ` Mel Gorman
2014-05-06 20:30   ` Peter Zijlstra

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=20140506155500.GA23991@suse.de \
    --to=mgorman@suse.de \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=vbabka@suse.cz \
    /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).