Messages in this thread | | | From | Denis Vlasenko <> | Subject | Re: kmalloc without GFP_xxx? | Date | Thu, 30 Jun 2005 10:52:54 +0300 |
| |
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/
| |