Re: kmalloc without GFP_xxx?

[Denis Vlasenko <vda@ilport.com.ua>]

On Wednesday 29 June 2005 19:48, Timur Tabi wrote:
> Denis Vlasenko wrote:
> 
> > This is why I always use _irqsave. Less error prone.
> 
> No, it's just bad programming.  How hard can it be to see which spinlocks are being used 
> by your ISR and which ones aren't?  Only the ones that your ISR touches should have 
> _irqsave.  It's really quite simple.

Given that I do not touch core kernel and most of spinlocks I ever
did were in drivers - yes, they are there to protect me from IRQ
handler races.

> > This is more or less what I meant. Why think about each kmalloc and when you
> > eventually did get it right: "Aha, we _sometimes_ get called from spinlocked code,
> > GFP_ATOMIC then" - you still do atomic alloc even if cases when you
> > were _not_ called from locked code! Thus you needed to think longer and got
> > code which is worse.
> 
> So you're saying that you're the kind of programmer who makes more mistakes the longer you 
> think about something?????

No.

I say that writing kmalloc(size, GFP_ATOMIC) takes more time to verify
that it is needed compared to hypothetical kmalloc_auto(size),
and yet kmalloc(size, GFP_ATOMIC) is worse in a sense thet it won't sleep
even if it happens to be called outside locks.

Think about this:

/* may be called under spinlock */
void do_something() {
	/* we need to alloc here */
}

> Using GFP_ATOMIC increases the probability that you won't be able to allocate the memory 
> you need, and it also increases the probability that some other module that really needs 
> GFP_ATOMIC will also be unable to allocate the memory it needs.  Please tell me, how is 
> this considered good programming?

Where did I say "let's use GFP_ATOMIC everywhere" ?
--
vda

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