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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>