lkml.org 
[lkml]   [2012]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] propagate gfp_t to page table alloc functions
On 04/27/2012 07:43 PM, David Rientjes wrote:

> On Fri, 27 Apr 2012, Minchan Kim wrote:
>
>>> Maybe a per-thread_info variant of gfp_allowed_mask? So Andrew's
>>> set_current_gfp() becomes set_current_gfp_allowed() that does
>>>
>>> void set_current_gfp_allowed(gfp_t gfp_mask)
>>> {
>>> current->gfp_allowed = gfp_mask & gfp_allowed_mask;
>>> }
>>>
>>> and then the page allocator does
>>>
>>> gfp_mask &= current->gfp_allowed;
>>>
>>> rather than how it currently does
>>>
>>> gfp_mask &= gfp_allowed_mask;
>>>
>>> and then the caller of set_current_gfp_allowed() cleans up with
>>> set_current_gfp_allowed(__GFP_BITS_MASK).
>>
>
> [trimmed the newsgroups from the reply, not sure what the point is?]
>
>> Caller should restore old gfp_mask instead of __GFP_BITS_MASK in case of
>> nesting.And how do we care of atomic context?
>>
>
> Eek, I'm hoping these aren't going to be nested but sure that seems
> appropraite if they are. (I'm also hoping these will only be either
> __GFP_HIGH or __GFP_BITS_MASK and no other combinations.)
>
> Forcing atomic context would just be set_current_gfp_allowed(__GFP_HIGH).


I mean it's not legal to access _current_ in atomic context so that
(gfp_mask &= current->gfp_allowed in page allocator) shouldn't.

--
Kind regards,
Minchan Kim


\
 
 \ /
  Last update: 2012-04-30 04:01    [W:0.082 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site