lkml.org 
[lkml]   [1998]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

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