Re: kmalloc without GFP_xxx?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux