[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Possible dcache BUG
Gene Heskett wrote:

>On Wednesday 11 August 2004 01:15, Linus Torvalds wrote:
>>On Tue, 10 Aug 2004, Linus Torvalds wrote:
>>>So I suspect it's a balancing issue. Possibly just the slight
>>>change in slab balancing to fix the highmem problems. Maybe we
>>>shrink slab _too_ aggressively or something.
>>Udo, that's a simple thing to check. If it's the slab balancing
>>changes, then you should be able to test it with just a
>> bk cset -x1.1830.4.3
>>if you have the current BK and are a BK user, or by just revertign
>>the patch here ("patch -R -p1" from inside your linux source tree)
>>if you're not a BK user..
>> Linus
>With the previously attached patch reverted, a fresh kernel builds in:
>real 7m18.296s
>user 5m49.385s
>sys 0m31.760s
>which is a marked improvement, but still about 1m30 or so slow.

This could easily be from too much slab pressure. How much memory do you
Have you got highmem turned on?

The new slab pressure calculation is an improvement in that it won't let
get out of control and cause OOMs, however it can shrink the slab too much.
If you regularly need ZONE_DMA pages, for example. AFAIKS there isn't
much you
can do about this except go to per-zone slab LRUs.

That said, your stability problems should be resolved first. If they are
and you would like to help track down the slowdown, run the kernel
compile about
3 times each with and without the patch, and save cat /proc/vmstat
before and
after each compile. Try to keep all else constant.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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