Messages in this thread | | | Date | Tue, 18 Aug 1998 21:40:40 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Notebooks |
| |
On 19 Aug 1998, Andi Kleen wrote: > > Me thinks it should have a better way to recover from out-of-memory errors > though than: > > (from tcp_send_fin)
This wasn't actually the one that locked up for me - the one that had problems was the much more normal "we need an skb for some data".
> /* Socket is locked, keep trying until memory is available. */ > do { > skb = sock_wmalloc(sk, > (MAX_HEADER + > sk->prot->max_header), > 1, GFP_KERNEL); > } while (skb == NULL);
This is actually going to work reasonably well with the new code. Certainly well enough for a small FIN-packet that really doesn't need much memory and easily fits in one page. So I wouldn't worry too much, and I certainly agree that there is no sense in even trying to clean it up for 2.2.
The mm layer was already pretty robust when it came to singe-page allocations, and as of 2.1.116 is should be robust for everything else too, within reason.
What really worries me is the slab stuff. I applied the diffs quite some time ago when David had integrated the "slabification" of the networking layer, but only today when I was chasing down this bug did I notice what really bad things it does. Not only does it use bigger page-orders than necessary, but the networking slabification in particular resulted in the fact that when you allocate a skb you now do _two_ allocations.
It used to be that we did one variable-length allocation that contained both the skb head and the actual data. But the slab code cannot handle variable-length allocations, so when somebody slabified it, they changed it to allocate the data separately. As such, the thing just slowed down, even though the whole intent of the slabs was to speed things up.
I really don't see the point there. It's slower, more complex, and uses more memory. Somebody please tell me why I shouldn't just get rid of it and revert to the old kmalloc(), which we know is stable and has none of these misfeatures?
Davem? Can you fill me in on why that was done in the first place?
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.altern.org/andrebalsa/doc/lkml-faq.html
| |