Messages in this thread | | | Date | Wed, 29 Jun 2005 13:43:59 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: kmalloc without GFP_xxx? |
| |
On Wed, 29 Jun 2005, Steven Rostedt wrote:
> > On Wed, 29 Jun 2005, 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. > > What about my argument that spin_lock is actually a longer latency on an > SMP system? That is, if you grab a spin_lock and task on another CPU > tries to grab it and starts to spin. It will spin while the first task is > servicing interrupts. It can be even worst with the following scenario: > > task 1: > spin_lock(&non_irq_lock); > > task 2: > > spin_lock_irqsave(&some_irq_used_lock); > spin_lock(&non_irq_lock); > > Here we see that task 2 can spin with interrupts off, while the first task > is servicing an interrupt, and God forbid if the IRQ handler sends some > kind of SMP signal to the CPU running task 2 since that would be a > deadlock. Granted, this is a hypothetical situation, but makes using > spin_lock with interrupts enabled a little scary. >
But it wouldn't deadlock! It would just spin until the guy on another CPU that had the lock unlocked.
FYI, spin_lock() is supposed to be used in an interrupt where it is already known that the interrupts are OFF so you don't need to save/restore flags because you know the condition. IFF the ISR were to enable interrupts, with a spin-lock held (bad practice), it still wouldn't deadlock, it's just that the entire system could potentially degenerate into a poll-mode, spin in the ISR, mode with awful performance.
> >>> 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????? >> >> 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? > > I believe he was trying to say that there might be a function that is > called by both an interrupt and non interrupt (schedulable) code. That > means that the code would always need to do a GFP_ATOMIC and yes, it would > mean that there's a higher chance that it would fail. So if you have some > function that's used by lots of schedulable code and that same function is > seldom used by an interrupt, then you either need to maintain two versions > of the function (one with GFP_ATOMIC and one without) or always use > GFP_ATOMIC which would mean the the majority user would suffer > unsuccessful allocations more often. > > -- Steve > - > 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/ >
Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - 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/
| |