lkml.org 
[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: lock_kernel() & kmalloc - evil together?
Date
In article <20000811002448.A27012@gruyere.muc.suse.de>,
Andi Kleen <ak@suse.de> wrote:
>
>When you cannot sleep you should use kmalloc(..., GFP_ATOMIC), but it is
>less reliable than GFP_KERNEL.

Also, you should try to avoid doing these kinds of operations inside a
spinlock, simply because they are slow (ATOMIC does not imply "fast", it
only implies that we won't schedule).

Rule of thumb: use GFP_ATOMIC only inside interrupt handlers or bottom
half routines. In any other case, try to just do the allocation before
you do the spinlock (or drop the lock and re-start).

It's not positively _wrong_ to do a GFP_ATOMIC inside a spinlock, it's
just something to be avoided as much as possible. Sometimes it is
unavoidable (or really ugly to avoid). But everybody should be aware of
the fact that the less you do inside a spinlock, the less contention you
will have (and this is often a super-linear effect - read some queueing
theory if you really care about the exact issues).

Linus

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

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.280 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site