On Wed, 11 Oct 2000 kuznet@xxxxxxxxxxxxx wrote:
> Hello!
>
> > Is it only the sleep while waiting for GFP_KERNEL memory allocation
> > which causes the deadlock problems?
> >
> > To the best of my understanding, yes, this was nbd's problem
> > precisely.
>
> I would add that Andi and Marcelo explained me that problem was not
> in sleep, but that GFP_KERNEL tries to shrink vm, which results
> in additional writes of cached pages, which in turn...
> Actually, it is big relief because trick with sk->allocation really helps.
>
> sendmsg, like any syscall, _sleeps_ and it is impossible to override
> with either sk->allocation and O_NONBLOCK. And even if it does
> not sleep in fact (f.e. in 2.2 or when socket is used exclusively
> by single thread in 2.4) it cannot be called with any spinning lock
> hold, from bh etc. Only from thread context free of any locks.
>
> BTW this does not apply to sock_alloc_send_skb, it can be called
> from any context provided you take precautions about nonblock,
> sk->allocation and do not use fallback.
>
> Only... one question:
>
> #define GFP_BUFFER (__GFP_HIGH | __GFP_WAIT)
>
> Old days GFP_BUFFER did not sleep.
> All the sense of fallback allocation was that it grabs large
> buffer provided it can make this without stressing memory.
> Should GFP_BUFFER be replaced with 0 now?
Reading core/sock.c (kernel 2.2), I've found: (sock_alloc_skb function)
if (fallback) {
/* The buffer get won't block, or use the atomic queue.
* It does produce annoying no free page messages still.
*/
skb = sock_wmalloc(sk, size, 0, GFP_BUFFER);
if (skb)
break;
try_size = fallback;
}
If I understood correctly, the code relies on that GFP_BUFFER allocations
will not sleep, right ?
If so, there is a problem, because GFP_BUFFER may sleep.
|