All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Sasha Levin <sasha.levin@oracle.com>,
	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 08/17] mm: page_alloc: Use word-based accesses for get/set pageblock bitmaps
Date: Tue, 6 May 2014 16:12:52 +0100	[thread overview]
Message-ID: <20140506151252.GZ23991@suse.de> (raw)
In-Reply-To: <5368F4CA.7060002@suse.cz>

On Tue, May 06, 2014 at 04:42:18PM +0200, Vlastimil Babka wrote:
> >>>+unsigned long get_pageblock_flags_mask(struct page *page,
> >>>+					unsigned long end_bitidx,
> >>>+					unsigned long nr_flag_bits,
> >>>+					unsigned long mask)
> >>>  {
> >>>  	struct zone *zone;
> >>>  	unsigned long *bitmap;
> >>>-	unsigned long pfn, bitidx;
> >>>-	unsigned long flags = 0;
> >>>-	unsigned long value = 1;
> >>>+	unsigned long pfn, bitidx, word_bitidx;
> >>>+	unsigned long word;
> >>>
> >>>  	zone = page_zone(page);
> >>>  	pfn = page_to_pfn(page);
> >>>  	bitmap = get_pageblock_bitmap(zone, pfn);
> >>>  	bitidx = pfn_to_bitidx(zone, pfn);
> >>>+	word_bitidx = bitidx / BITS_PER_LONG;
> >>>+	bitidx &= (BITS_PER_LONG-1);
> >>>
> >>>-	for (; start_bitidx <= end_bitidx; start_bitidx++, value <<= 1)
> >>>-		if (test_bit(bitidx + start_bitidx, bitmap))
> >>>-			flags |= value;
> >>>-
> >>>-	return flags;
> >>>+	word = bitmap[word_bitidx];
> >>
> >>I wonder if on some architecture this may result in inconsistent
> >>word when racing with set(), i.e. cmpxchg? We need consistency at
> >>least on the granularity of byte to prevent the problem with bogus
> >>migratetype values being read.
> >>fix:
> >
> >The number of bits align on the byte boundary so I do not think there is
> >a problem there. There is a BUILD_BUG_ON check in set_pageblock_flags_mask
> >in case this changes so it can be revisited if necessary.
> 
> I was wondering about hardware guarantees in that case (e.g.
> consistency at least on the granularity of byte when a simple memory
> read races with write) but after some discussion in the office I
> understand that hardware without such guarantees wouldn't be able to
> run Linux anyway :)
> 
> Still I wonder if ACCESS_ONCE would be safer in the 'word' variable
> assignment to protect against compiler trying to be too smart?
> 

I couldn't see a case in the get path where it would matter. I put an
ACCESS_ONCE in the set path in case the compiler accidentally determined
that old_word was invariant in that loop.

> Anyway with the nr_flag_bits removed:
> 
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
> 

Thanks.

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

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Sasha Levin <sasha.levin@oracle.com>,
	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 08/17] mm: page_alloc: Use word-based accesses for get/set pageblock bitmaps
Date: Tue, 6 May 2014 16:12:52 +0100	[thread overview]
Message-ID: <20140506151252.GZ23991@suse.de> (raw)
In-Reply-To: <5368F4CA.7060002@suse.cz>

On Tue, May 06, 2014 at 04:42:18PM +0200, Vlastimil Babka wrote:
> >>>+unsigned long get_pageblock_flags_mask(struct page *page,
> >>>+					unsigned long end_bitidx,
> >>>+					unsigned long nr_flag_bits,
> >>>+					unsigned long mask)
> >>>  {
> >>>  	struct zone *zone;
> >>>  	unsigned long *bitmap;
> >>>-	unsigned long pfn, bitidx;
> >>>-	unsigned long flags = 0;
> >>>-	unsigned long value = 1;
> >>>+	unsigned long pfn, bitidx, word_bitidx;
> >>>+	unsigned long word;
> >>>
> >>>  	zone = page_zone(page);
> >>>  	pfn = page_to_pfn(page);
> >>>  	bitmap = get_pageblock_bitmap(zone, pfn);
> >>>  	bitidx = pfn_to_bitidx(zone, pfn);
> >>>+	word_bitidx = bitidx / BITS_PER_LONG;
> >>>+	bitidx &= (BITS_PER_LONG-1);
> >>>
> >>>-	for (; start_bitidx <= end_bitidx; start_bitidx++, value <<= 1)
> >>>-		if (test_bit(bitidx + start_bitidx, bitmap))
> >>>-			flags |= value;
> >>>-
> >>>-	return flags;
> >>>+	word = bitmap[word_bitidx];
> >>
> >>I wonder if on some architecture this may result in inconsistent
> >>word when racing with set(), i.e. cmpxchg? We need consistency at
> >>least on the granularity of byte to prevent the problem with bogus
> >>migratetype values being read.
> >>fix:
> >
> >The number of bits align on the byte boundary so I do not think there is
> >a problem there. There is a BUILD_BUG_ON check in set_pageblock_flags_mask
> >in case this changes so it can be revisited if necessary.
> 
> I was wondering about hardware guarantees in that case (e.g.
> consistency at least on the granularity of byte when a simple memory
> read races with write) but after some discussion in the office I
> understand that hardware without such guarantees wouldn't be able to
> run Linux anyway :)
> 
> Still I wonder if ACCESS_ONCE would be safer in the 'word' variable
> assignment to protect against compiler trying to be too smart?
> 

I couldn't see a case in the get path where it would matter. I put an
ACCESS_ONCE in the set path in case the compiler accidentally determined
that old_word was invariant in that loop.

> Anyway with the nr_flag_bits removed:
> 
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
> 

Thanks.

-- 
Mel Gorman
SUSE Labs

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

Thread overview: 113+ 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 ` 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  8:44   ` Mel Gorman
2014-05-01 13:25   ` Johannes Weiner
2014-05-01 13:25     ` Johannes Weiner
2014-05-06 15:04   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 15:09   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 15:10   ` Rik van Riel
2014-05-06 15:10     ` Rik van Riel
2014-05-06 20:23   ` Peter Zijlstra
2014-05-06 20:23     ` Peter Zijlstra
2014-05-06 22:21     ` Mel Gorman
2014-05-06 22:21       ` Mel Gorman
2014-05-07  9:04       ` Peter Zijlstra
2014-05-07  9:43         ` Mel Gorman
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-01  8:44   ` Mel Gorman
2014-05-06 16:01   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 16:48   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 17:24   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 17:25   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-02 22:34   ` Sasha Levin
2014-05-02 22:34     ` Sasha Levin
2014-05-04 13:14     ` Mel Gorman
2014-05-04 13:14       ` Mel Gorman
2014-05-05 12:40       ` Vlastimil Babka
2014-05-05 12:40         ` Vlastimil Babka
2014-05-06  9:13         ` Mel Gorman
2014-05-06  9:13           ` Mel Gorman
2014-05-06 14:42           ` Vlastimil Babka
2014-05-06 14:42             ` Vlastimil Babka
2014-05-06 15:12             ` Mel Gorman [this message]
2014-05-06 15:12               ` Mel Gorman
2014-05-06 20:34   ` Peter Zijlstra
2014-05-06 20:34     ` Peter Zijlstra
2014-05-06 22:24     ` Mel Gorman
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-01  8:44   ` Mel Gorman
2014-05-06 18:47   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 18:48   ` Rik van Riel
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  8:44   ` Mel Gorman
2014-05-01 14:35   ` Dave Hansen
2014-05-01 14:35     ` Dave Hansen
2014-05-01 15:11     ` Mel Gorman
2014-05-01 15:11       ` Mel Gorman
2014-05-01 15:38       ` Dave Hansen
2014-05-01 15:38         ` Dave Hansen
2014-05-06 18:49   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 18:49   ` Rik van Riel
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-01  8:44   ` Mel Gorman
2014-05-06 18:53   ` Rik van Riel
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  8:44   ` Mel Gorman
2014-05-01 13:29   ` Johannes Weiner
2014-05-01 13:29     ` Johannes Weiner
2014-05-01 13:39     ` Mel Gorman
2014-05-01 13:39       ` Mel Gorman
2014-05-01 13:47       ` Johannes Weiner
2014-05-01 13:47         ` Johannes Weiner
2014-05-06 18:54   ` Rik van Riel
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  8:44   ` Mel Gorman
2014-05-01 13:33   ` Johannes Weiner
2014-05-01 13:33     ` Johannes Weiner
2014-05-01 13:40     ` Mel Gorman
2014-05-01 13:40       ` Mel Gorman
2014-05-06 15:30   ` Vlastimil Babka
2014-05-06 15:30     ` Vlastimil Babka
2014-05-06 15:55     ` Mel Gorman
2014-05-06 15:55       ` Mel Gorman
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   ` 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-01  8:44   ` Mel Gorman
2014-05-05 10:50   ` Jan Kara
2014-05-05 10:50     ` Jan Kara
2014-05-07  9:03     ` Mel Gorman
2014-05-07  9:03       ` Mel Gorman
2014-05-06 20:30   ` Peter Zijlstra
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=20140506151252.GZ23991@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=sasha.levin@oracle.com \
    --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 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.