lkml.org 
[lkml]   [2009]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] mm: Introduce GFP_PANIC for early-boot allocations
    Ingo Molnar wrote:
    > * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
    >
    >> Hi Andrew,
    >>
    >> Andrew Morton wrote:
    >>> On Fri, 08 May 2009 18:10:28 +0300
    >>> Pekka Enberg <penberg@cs.helsinki.fi> wrote:
    >>>
    >>>> +#define GFP_PANIC (__GFP_NOFAIL | __GFP_NORETRY)
    >>> urgh, you have to be kidding me. This significantly worsens complexity
    >>> and risk in core MM and it's just yuk.
    >>>
    >>> I think we can justify pulling such dopey party tricks to save
    >>> pageframe space, or bits in page.flags and such. But just to
    >>> save a scrap of memory which would have been released during boot
    >>> anwyay? Don't think so.
    >> No, I wasn't kidding and I don't agree that it "significantly
    >> worsens complexity". The point is not to save memory but to
    >> clearly annotate those special call-sites that really don't need
    >> to check for out-of-memory.
    >
    > Frankly, i cannot believe that so many smart people dont see the
    > simple, universal, un-arguable truism in the following statement:
    >
    > it is shorter, tidier, more maintainable, more reviewable to write:
    >
    > ptr = kmalloc(GFP_BOOT, size);
    >
    > than to write:
    >
    > ptr = kmalloc(GFP_KERNEL, size);
    > BUG_ON(!ptr);

    Hey, that's a much better name! I guess we don't need to support
    GFP_ATOMIC? I'll repost the series with Peter's system_state != BOOTING
    warning. Lets see if that makes the patch more palatable to Andrew.

    Pekka


    \
     
     \ /
      Last update: 2009-05-09 11:27    [W:0.021 / U:91.024 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site