Re: [PATCH 1/2] mm: Introduce GFP_PANIC for early-boot allocations

From: Ingo Molnar
Date: Sat May 09 2009 - 05:32:06 EST



* Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:

> Ingo Molnar wrote:
>> * Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
>>
>>> Hi Andrew,
>>>
>>> Andrew Morton wrote:
>>>> On Fri, 08 May 2009 18:10:28 +0300
>>>> Pekka Enberg <penberg@xxxxxxxxxxxxxx> 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.

Hey, and as we all know, names do matter! We are much better off
hacking Linux not Freax, after all.

Successful projects need good names, and anyone who doesnt know that
must be a true git. Hm, wait a minute ...

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/