linux-kernel - Re: [merged] mm-page_alloc-reset-aging-cycle-with-gfp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Mar 2014 18:04:04 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	stable@...nel.org, riel@...hat.com, mgorman@...e.de,
	jstancek@...hat.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [merged]
 mm-page_alloc-reset-aging-cycle-with-gfp_thisnode-v2.patch removed from -mm
 tree

On Thu, Mar 06, 2014 at 01:56:35PM -0800, Andrew Morton wrote:
> On Thu, 6 Mar 2014 16:49:27 -0500 Johannes Weiner <hannes@...xchg.org> wrote:
> 
> > On Thu, Mar 06, 2014 at 12:37:57PM -0800, akpm@...ux-foundation.org wrote:
> > > Subject: [merged] mm-page_alloc-reset-aging-cycle-with-gfp_thisnode-v2.patch removed from -mm tree
> > > To: hannes@...xchg.org,jstancek@...hat.com,mgorman@...e.de,riel@...hat.com,stable@...nel.org,mm-commits@...r.kernel.org
> > > From: akpm@...ux-foundation.org
> > > Date: Thu, 06 Mar 2014 12:37:57 -0800
> > > 
> > > 
> > > The patch titled
> > >      Subject: mm: page_alloc: exempt GFP_THISNODE allocations from zone fairness
> > > has been removed from the -mm tree.  Its filename was
> > >      mm-page_alloc-reset-aging-cycle-with-gfp_thisnode-v2.patch
> > > 
> > > This patch was dropped because it was merged into mainline or a subsystem tree
> > 
> > Would it make sense to also merge
> > 
> > mm-fix-gfp_thisnode-callers-and-clarify.patch
> > 
> > at this point?  It's not as critical as the GFP_THISNODE exemption,
> > which is why I didn't tag it for stable, but it's a bugfix as well.
> 
> Changelog fail!
> 
> : GFP_THISNODE is for callers that implement their own clever fallback to
> : remote nodes, and so no direct reclaim is invoked.  There are many current
> : users that only want node exclusiveness but still want reclaim to make the
> : allocation happen.  Convert them over to __GFP_THISNODE and update the
> : documentation to clarify GFP_THISNODE semantics.
> 
> what bug does it fix and what are the user-visible effects??

Ok, maybe this is better?

---

GFP_THISNODE is for callers that implement their own clever fallback
to remote nodes.  It restricts the allocation to the specified node
and does not invoke reclaim, assuming that the caller will take care
of it when the fallback fails, e.g. through a subsequent allocation
request without GFP_THISNODE set.

However, many current GFP_THISNODE users only want the node exclusive
aspect of the flag, without actually implementing their own fallback
or triggering reclaim if necessary.  This results in things like page
migration failing prematurely even when there is easily reclaimable
memory available, unless kswapd happens to be running already or a
concurrent allocation attempt triggers the necessary reclaim.

Convert all callsites that don't implement their own fallback strategy
to __GFP_THISNODE.  This restricts the allocation a single node too,
but at the same time allows the allocator to enter the slowpath, wake
kswapd, and invoke direct reclaim if necessary, to make the allocation
happen when memory is full.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/