On 27.2.2015 23:31, David Rientjes wrote:
On Fri, 27 Feb 2015, Vlastimil Babka wrote:
Do you see any issues with either patch 1/2 or patch 2/2 besides the
s/GFP_TRANSHUGE/GFP_THISNODE/ that is necessary on the changelog?
Well, my point is, what if the node we are explicitly trying to allocate
On Fri, 27 Feb 2015, Vlastimil Babka wrote:
> > Do you see any issues with either patch 1/2 or patch 2/2 besides the
> > s/GFP_TRANSHUGE/GFP_THISNODE/ that is necessary on the changelog?
>
> Well, my point is, what if the node we are explicitly trying to allocate
> hugepage on, is in fact not al
On 02/27/2015 11:03 PM, David Rientjes wrote:
>> With both
>> patches they won't bail out and __GFP_NO_KSWAPD will prevent most of the
>> stuff
>> described above, including clearing ALLOC_CPUSET.
>
> Yeah, ALLOC_CPUSET is never cleared for thp allocations because atomic ==
> false for thp, rega
On Fri, 27 Feb 2015, Vlastimil Babka wrote:
> Oh, right. I missed the new trigger. My sanity and career is saved!
>
Haha.
> Well, no... the flags are still a mess. Aren't GFP_TRANSHUGE | __GFP_THISNODE
> allocations still problematic after this patch and 2/2? Those do include
> __GFP_WAIT (unle
On 02/27/2015 04:09 AM, David Rientjes wrote:
> On Thu, 26 Feb 2015, Vlastimil Babka wrote:
>
>> > to restrict an allocation to a local node, but remove GFP_TRANSHUGE and
>> > it's obscurity. Instead, we require that a caller clear __GFP_WAIT if it
>> > wants to avoid reclaim.
>> >
>> > This all
On Thu, 26 Feb 2015, Vlastimil Babka 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_NO
On 02/26/2015 01:23 AM, 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
On Wed, 25 Feb 2015, Christoph Lameter wrote:
> On Wed, 25 Feb 2015, David Rientjes wrote:
>
> > NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
>
> Well but then its not removing it. You are replacing it with an inline
> function.
>
Removing GFP_THISNODE, not __GFP_TH
On Wed, 25 Feb 2015, David Rientjes wrote:
> NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
Well but then its not removing it. You are replacing it with an inline
function.
> +
> +/*
> + * Construct gfp mask to allocate from a specific node but do not invoke
> reclaim
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
10 matches
Mail list logo
