On Mon, 2 Mar 2015, Vlastimil Babka wrote:
> > > > You are thinking about an opportunistic allocation attempt in SLAB?
> > > >
> > > > AFAICT SLAB allocations should trigger reclaim.
> > > >
> > >
> > > Well, let me quote your commit 952f3b51beb5:
> >
> > This was about global reclaim. Local
On 03/02/2015 05:08 PM, Christoph Lameter wrote:
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
You are thinking about an opportunistic allocation attempt in SLAB?
AFAICT SLAB allocations should trigger reclaim.
Well, let me quote your commit 952f3b51beb5:
This was about global reclaim.
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
> > You are thinking about an opportunistic allocation attempt in SLAB?
> >
> > AFAICT SLAB allocations should trigger reclaim.
> >
>
> Well, let me quote your commit 952f3b51beb5:
This was about global reclaim. Local reclaim is good and that can be
On 03/02/2015 04:46 PM, Christoph Lameter wrote:
> On Mon, 2 Mar 2015, Vlastimil Babka wrote:
>
>> So it would be IMHO better for longer-term maintainability to have the
>> relevant __GFP_THISNODE callers pass also __GFP_NO_KSWAPD to denote these
>> opportunistic allocation attempts, instead of
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
> So it would be IMHO better for longer-term maintainability to have the
> relevant __GFP_THISNODE callers pass also __GFP_NO_KSWAPD to denote these
> opportunistic allocation attempts, instead of having this subtle semantic
You are thinking about an
On 02/27/2015 11:16 PM, David Rientjes wrote:
NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
GFP_THISNODE is a secret combination of gfp bits that have different
behavior than expected. It is a combination of __GFP_THISNODE,
__GFP_NORETRY, and __GFP_NOWARN and is
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
You are thinking about an opportunistic allocation attempt in SLAB?
AFAICT SLAB allocations should trigger reclaim.
Well, let me quote your commit 952f3b51beb5:
This was about global reclaim. Local reclaim is good and that
On 02/27/2015 11:16 PM, David Rientjes wrote:
NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
GFP_THISNODE is a secret combination of gfp bits that have different
behavior than expected. It is a combination of __GFP_THISNODE,
__GFP_NORETRY, and __GFP_NOWARN and is
On 03/02/2015 05:08 PM, Christoph Lameter wrote:
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
You are thinking about an opportunistic allocation attempt in SLAB?
AFAICT SLAB allocations should trigger reclaim.
Well, let me quote your commit 952f3b51beb5:
This was about global reclaim.
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
So it would be IMHO better for longer-term maintainability to have the
relevant __GFP_THISNODE callers pass also __GFP_NO_KSWAPD to denote these
opportunistic allocation attempts, instead of having this subtle semantic
You are thinking about an
On 03/02/2015 04:46 PM, Christoph Lameter wrote:
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
So it would be IMHO better for longer-term maintainability to have the
relevant __GFP_THISNODE callers pass also __GFP_NO_KSWAPD to denote these
opportunistic allocation attempts, instead of having
On Mon, 2 Mar 2015, Vlastimil Babka wrote:
You are thinking about an opportunistic allocation attempt in SLAB?
AFAICT SLAB allocations should trigger reclaim.
Well, let me quote your commit 952f3b51beb5:
This was about global reclaim. Local reclaim is good and that can be
done via
On Fri, 27 Feb 2015, Christoph Lameter wrote:
> > +/*
> > + * Construct gfp mask to allocate from a specific node but do not invoke
> > reclaim
> > + * or warn about failures.
> > + */
>
> We should be triggering reclaim from slab allocations. Why would we not do
> this?
>
> Otherwise we will
On Fri, 27 Feb 2015, David Rientjes wrote:
> +/*
> + * Construct gfp mask to allocate from a specific node but do not invoke
> reclaim
> + * or warn about failures.
> + */
We should be triggering reclaim from slab allocations. Why would we not do
this?
Otherwise we will be going uselessly off
NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
GFP_THISNODE is a secret combination of gfp bits that have different
behavior than expected. It is a combination of __GFP_THISNODE,
__GFP_NORETRY, and __GFP_NOWARN and is special-cased in the page allocator
slowpath to fail
On Fri, 27 Feb 2015, Christoph Lameter wrote:
+/*
+ * Construct gfp mask to allocate from a specific node but do not invoke
reclaim
+ * or warn about failures.
+ */
We should be triggering reclaim from slab allocations. Why would we not do
this?
Otherwise we will be going
NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
GFP_THISNODE is a secret combination of gfp bits that have different
behavior than expected. It is a combination of __GFP_THISNODE,
__GFP_NORETRY, and __GFP_NOWARN and is special-cased in the page allocator
slowpath to fail
On Fri, 27 Feb 2015, David Rientjes wrote:
+/*
+ * Construct gfp mask to allocate from a specific node but do not invoke
reclaim
+ * or warn about failures.
+ */
We should be triggering reclaim from slab allocations. Why would we not do
this?
Otherwise we will be going uselessly off node
18 matches
Mail list logo
