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:4.166 / U:0.328 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site