lkml.org 
[lkml]   [1998]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Notebooks
Date
In article <6rd6ek$sr9$1@work.noris.de>,
Matthias Urlichs <smurf@noris.de> wrote:
> torvalds@transmeta.com (Linus Torvalds) writes:
>>
>> In this case, TCP wanted to allocate a single skb, and due to slabs this
>> got turned into a multi-page request even though it fit perfectly fine
>> into one page. Thus a critical allocation could fail, and the TCP layer
>> started looping - and kswapd could never even try to fix it up because
>> the TCP code held the kernel lock.
>>
>Methinks that TCP ought to be able to recover from out-of-memory conditions,
>just like any other part of the kernel. If slabs make those things which
>fall over when they don't get their memory fall over more often, that's
>fine with me: it means we get to find more bugs. ;-)

I've certainly fixed the problem as far as I'm able to see it, and my
fix makes a lot of sense regardless of whether we use slab or something
else. And I cannot make it break like I used to be able to.

That doesn't mean that I like the slab code. I've never been very
thrilled about how is blithely assumes that it's ok to just allocate
higher orders of pages, and this just made it even more clear that that
was not a good design choice in the slab code. "Finding problems" is
not a good enough excuse for being fragile.

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.073 / U:4.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site