On Wed, 25 Feb 2015, Mel Gorman wrote:
> On Fri, Feb 20, 2015 at 07:56:15PM -0800, Hugh Dickins wrote:
> > Commit 07a427884348 ("mm: shmem: avoid atomic operation during
> > shmem_getpage_gfp") rightly replaced one instance of SetPageSwapBacked
> > by __SetPageSwapBacked, pointing out that the newly allocated page is
> > not yet visible to other users (except speculative get_page_unless_zero-
> > ers, who may not update page flags before their further checks).
> >
> > That was part of a series in which Mel was focused on tmpfs profiles:
> > but almost all SetPageSwapBacked uses can be so optimized, with the
> > same justification. And remove the ClearPageSwapBacked from
> > read_swap_cache_async()'s and zswap_get_swap_cache_page()'s error
> > paths: it's not an error to free a page with PG_swapbacked set.
> >
> > (There's probably scope for further __SetPageFlags in other places,
> > but SwapBacked is the one I'm interested in at the moment.)
> >
> > Signed-off-by: Hugh Dickins <hu...@google.com>
> > ---
> > mm/migrate.c | 6 +++---
> > mm/rmap.c | 2 +-
> > mm/shmem.c | 4 ++--
> > mm/swap_state.c | 3 +--
> > mm/zswap.c | 3 +--
> > 5 files changed, 8 insertions(+), 10 deletions(-)
> >
> > <SNIP>
> > --- thpfs.orig/mm/shmem.c 2015-02-08 18:54:22.000000000 -0800
> > +++ thpfs/mm/shmem.c 2015-02-20 19:33:35.676074594 -0800
> > @@ -987,8 +987,8 @@ static int shmem_replace_page(struct pag
> > flush_dcache_page(newpage);
> >
> > __set_page_locked(newpage);
> > + __SetPageSwapBacked(newpage);
> > SetPageUptodate(newpage);
> > - SetPageSwapBacked(newpage);
> > set_page_private(newpage, swap_index);
> > SetPageSwapCache(newpage);
> >
>
> It's clear why you did this but ...
>
> > @@ -1177,8 +1177,8 @@ repeat:
> > goto decused;
> > }
> >
> > - __SetPageSwapBacked(page);
> > __set_page_locked(page);
> > + __SetPageSwapBacked(page);
> > if (sgp == SGP_WRITE)
> > __SetPageReferenced(page);
> >
>
> It's less clear why this was necessary.
I don't think the reordering was necessary in either case
(though perhaps the first hunk makes a subsequent patch smaller).
I just get irritated by seeing the same lines of code permuted
in different ways for no reason, and thought I'd tidy them up
to establish one familiar sequence, that's all.
> I don't think it causes any problems though so
>
> Reviewed-by: Mel Gorman <mgor...@suse.de>
Thanks!
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
