Notebooks
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
In article <[email protected]>,
Quoted 11 lines · Alan Cox
Quoted 4 lines
We really gotta stop calling them "unstable" as they're not. They're developemental. Miy firewall's running 2.1.10X and it's been up amost 2 months I think. My desktop is 2.1.115 and the only reason I rebootyed it was to install that instead of 2.1.110...
Squid on 2.1.115 (with or without ac1) lasts 60 seconds on my soak test before it explodes. Ditto a lot of other high load tests that touch I/O or VM hard. (Note Im guessing where it dies here). Some of 2.1.x is rock solid, and some bits of it are solid in non extreme use, but 2.1.x is not remotely stable for real world hard use yet. Its getting there bit by bit
Ok, I found this.
Once more, it was the slab stuff that broke badly. I'm going to consider just throwing out the slabs for v2.2 unless somebody is willing to stand up and fix it - the multi-page allocation stuff just breaks too horribly.
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.
I'm going to fix this particular case even with slabs, but this isn't the first time the slabs "optimizations" have just broken code that used to work fine by making it a high-order allocation. Essentially, the slabsified kmalloc() is just a lot more fragile than the original kmalloc() was.
(This also shows a particularly nasty inefficiency - the TCP code explicitly tries to have a "good" MTU for loopback, and it's meant to fit in a single page. The slab code makes it fail miserably in that objective).
All sane architectures are moving to at least 2-way caches and the good ones are 4-way or more. As such, slabs optimizes for the wrong case.
Linus
--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]
Hi,
Quoted 6 lines · Linus Torvalds
Ok, I found this.
Once more, it was the slab stuff that broke badly. I'm going to consider just throwing out the slabs for v2.2 unless somebody is willing to stand up and fix it - the multi-page allocation stuff just breaks too horribly.
/* If the num of objs per slab is <= SLAB_MIN_OBJS_PER_SLAB,
* then the page order must be less than this before trying the next order.
*/
#define SLAB_BREAK_GFP_ORDER_HI 2
#define SLAB_BREAK_GFP_ORDER_LO 1replace orders with 0; no more unnecessary higher-order allocations. We want this to be configurable at boot time, however; the extra efficiency may be worth it on larger memory machines. Linus, I'll do this if you want it: default all the BREAK orders to 0 and add a boot option to increase it.
Quoted 5 lines
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.
If the network stack can loop on an allocation without dropping the lock, then even single-page allocations can deadlock. (If there's a lot of dirty data in swap, kswapd can quite easily block with no free pages present for a time, especially if there is high network load at the time.)
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]
I have this fixed in my tree, it's been fixed in my tree for 3 months, and if you hadn't stopped me half-way through my last merge to you, you would have gotten it. Don't blame slab in this case, that original loopback MTU value was tuned for the old kmalloc and old skb allocation routines.
Later,
David S. Miller
[email protected]
--
This is a majordomo managed list. To unsubscribe, send a message with the body 'unsubscribe linux-mm me@address' to: [email protected]