2.5.33-mm2

2.5.33-mm2

[Andrew Morton]

- Linus has merged ia32 NUMA discontigmem support

+ Added a little cleanup patch from various folks.


Threw in the kichen sink:

+writeback-control.patch

  Infrastructure for richer communication between the block layer
  and the VM.

+queue-congestion.patch

  Infrastructure for non-blocking writeout in the block layer.

+nonblocking-pdflush.patch

  Non-blocking background writeback

+nonblocking-vm.patch

  Non-blocking page reclaim.

This is all about reducing latency when the machine is performing heavy
writeback, which has been a significant performance problem for ever.
The code also happens to provide improved scalability in many-spindle
pagecache writeback.

The code is stable, but by no means complete.  Under some loads it will
chew tons of CPU in page reclaim.

But with mem=512m and four instances of `dbench 100' each against a
different disk the machine was 100% responsive and ran a `make -j6
bzImage' in three minutes.  Without these patches the kernel took over
five minutes just to unpack the kernel tarball.



linus.patch
  cset-1.575-to-1.600.txt.gz

scsi_hack.patch
  Fix block-highmem for scsi

ext3-htree.patch
  Indexed directories for ext3

zone-pages-reporting.patch
  Fix the boot-time reporting of each zone's available pages

enospc-recovery-fix.patch
  Fix the __block_write_full_page() error path.

fix-faults.patch
  Back out the initial work for atomic copy_*_user()

spin-lock-check.patch
  spinlock/rwlock checking infrastructure

refill-rate.patch
  refill the inactive list more quickly

copy_user_atomic.patch

kmap_atomic_reads.patch
  Use kmap_atomic() for generic_file_read()

kmap_atomic_writes.patch
  Use kmap_atomic() for generic_file_write()

throttling-fix.patch
  Fix throttling of heavy write()rs.

dirty-state-accounting.patch
  Make the global dirty memory accounting more accurate

rd-cleanup.patch
  Cleanup and fix the ramdisk driver (doesn't work right yet)

discontig-cleanup-1.patch
  i386 discontigmem coding cleanups

discontig-cleanup-2.patch
  i386 discontigmem cleanups

writeback-thresholds.patch
  Downward adjustments to the default dirtymemory thresholds

buffer-strip.patch
  Limit the consumption of ZONE_NORMAL by buffer_heads

rmap-speedup.patch
  rmap pte_chain space and CPU reductions

wli-highpte.patch
  Resurrect CONFIG_HIGHPTE - ia32 pagetables in highmem

readv-writev.patch
  O_DIRECT support for readv/writev

slablru.patch
  age slab pages on the LRU

slablru-speedup.patch
  slablru optimisations

llzpr.patch
  Reduce scheduling latency across zap_page_range

buffermem.patch
  Resurrect buffermem accounting

config-PAGE_OFFSET.patch
  Configurable kenrel/user memory split

lpp.patch
  ia32 huge tlb pages

ext3-sb.patch
  u.ext3_sb -> generic_sbp

oom-fix.patch
  Fix an OOM condition on big highmem machines

tlb-cleanup.patch
  Clean up the tlb gather code

dump-stack.patch
  arch-neutral dump_stack() function

wli-cleanup.patch
  random cleanups

madvise-move.patch
  move mdavise implementation into mm/madvise.c

split-vma.patch
  VMA splitting patch

buffer-ops-move.patch
  Move submit_bh() and ll_rw_block() into fs/buffer.c

writeback-control.patch
  Cleanup and extension of the writeback paths

queue-congestion.patch
  Infrastructure for communicating request queue congestion to the VM

nonblocking-pdflush.patch
  non-blocking writeback infrastructure, use it for pdflush

nonblocking-vm.patch
  Non-blocking page reclaim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm2

[Andrew Morton]

hm.  I sent this email to lkml and linux-mm.  The one on lkml had
a URL at the top.  But linux-mm chopped it off.

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.33/2.5.33-mm2/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm2

[Stephen C. Tweedie]

Hi,

On Wed, Sep 04, 2002 at 02:32:51AM -0700, Andrew Morton wrote:
> hm.  I sent this email to lkml and linux-mm.  The one on lkml had
> a URL at the top.  But linux-mm chopped it off.

Not quite --- linux-mm turned it into a header. :-)

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm2

[Adam Kropelin]

Seems to need this patch to satisfy the compiler gremlins...

--Adam

--- linux-2.5.33-mm2.orig/mm/vmalloc.c	Wed Sep  4 11:42:50 2002
+++ linux-2.5.33-mm2/mm/vmalloc.c	Wed Sep  4 11:38:53 2002
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/vmalloc.h>
+#include <linux/interrupt.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgalloc.h>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Paul Larson]

I havn't tried this with stock 2.5.33 or 2.5.33-mm2 yet, but I was
trying the old fork07 ltp test and got a problem when I was testing
mm1.  The fork bomb part of that test is now in the fork12 test in LTP
and is not run by runalltests anymore due to the recent kernel changes. 
Here's the ksymoops output for now, and I'll see about trying to
reproduce it.

Thanks,
Paul Larson

Unable to handle kernel NULL pointer dereference at virtual address
00000004
c0131ef0
*pde = 28d4e001
Oops: 0002
CPU:    5
EIP:    0060:[<c0131ef0>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 00000000   ebx: c17a67b0   ecx: 00000000   edx: 00000000
esi: e8cd3000   edi: 00000000   ebp: cd0f8660   esp: e8d53d20
ds: 0068   es: 0068   ss: 0068
Stack: 00000001 e8d53de8 c17a67b0 c17a67b0 0000000f c0133b2d c17a67b0
00000001
       00000000 00000020 ed9fea24 00000000 c17ad5d8 c181aaa8 00000000
00000000
       e8dcf320 00000000 00000001 00000005 00000014 00000005 c01115f0
00000000
Call Trace: [<c0133b2d>] [<c01115f0>] [<c0109636>] [<c0107fba>]
[<c0134056>]
   [<c013cdda>] [<c013cd30>] [<c0134687>] [<c01346f1>] [<c013473e>]
[<c01353c3>]
   [<c0135712>] [<c0135790>] [<c0117747>] [<c01181e6>] [<c0107fba>]
[<c0118a43>]
   [<c0115b4d>] [<c01115f0>] [<c0105d47>] [<c01075f3>]
Code: 89 50 04 89 02 c7 06 00 00 00 00 c7 46 04 00 00 00 00 d3 24

>>EIP; c0131ef0 <kmem_shrink_slab+40/b0>   <=====
Trace; c0133b2d <shrink_list+cd/440>
Trace; c01115f0 <smp_apic_timer_interrupt+e0/120>
Trace; c0109636 <do_IRQ+f6/110>
Trace; c0107fba <apic_timer_interrupt+1a/20>
Trace; c0134056 <shrink_cache+1b6/320>
Trace; c013cdda <wakeup_bdflush+1a/20>
Trace; c013cd30 <background_writeout+0/90>
Trace; c0134687 <shrink_zone+87/c0>
Trace; c01346f1 <shrink_caches+31/50>
Trace; c013473e <try_to_free_pages+2e/70>
Trace; c01353c3 <balance_classzone+43/200>
Trace; c0135712 <__alloc_pages+192/200>
Trace; c0135790 <__get_free_pages+10/20>
Trace; c0117747 <dup_task_struct+17/80>
Trace; c01181e6 <copy_process+56/890>
Trace; c0107fba <apic_timer_interrupt+1a/20>
Trace; c0118a43 <do_fork+23/b0>
Trace; c0115b4d <schedule+33d/370>
Trace; c01115f0 <smp_apic_timer_interrupt+e0/120>
Trace; c0105d47 <sys_fork+17/30>
Trace; c01075f3 <syscall_call+7/b>
Code;  c0131ef0 <kmem_shrink_slab+40/b0>
00000000 <_EIP>:
Code;  c0131ef0 <kmem_shrink_slab+40/b0>   <=====
   0:   89 50 04                  mov    %edx,0x4(%eax)   <=====
Code;  c0131ef3 <kmem_shrink_slab+43/b0>
   3:   89 02                     mov    %eax,(%edx)
Code;  c0131ef5 <kmem_shrink_slab+45/b0>
   5:   c7 06 00 00 00 00         movl   $0x0,(%esi)
Code;  c0131efb <kmem_shrink_slab+4b/b0>
   b:   c7 46 04 00 00 00 00      movl   $0x0,0x4(%esi)
Code;  c0131f02 <kmem_shrink_slab+52/b0>
  12:   d3 24 00                  shll   %cl,(%eax,%eax,1)


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Andrew Morton]

Paul Larson wrote:
> 
> I havn't tried this with stock 2.5.33 or 2.5.33-mm2 yet, but I was
> trying the old fork07 ltp test and got a problem when I was testing
> mm1.  The fork bomb part of that test is now in the fork12 test in LTP
> and is not run by runalltests anymore due to the recent kernel changes.
> Here's the ksymoops output for now, and I'll see about trying to
> reproduce it.
> 
> ..
> >>EIP; c0131ef0 <kmem_shrink_slab+40/b0>   <=====


hm.  We seem to have a corrupted slabp->list.  I don't recall any
slab fixes post 2.3.33-mm1.  hm.

Questions, please: how much physical memory, how many CPUs?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Paul Larson]

On Wed, 2002-09-04 at 13:02, Andrew Morton wrote:
> hm.  We seem to have a corrupted slabp->list.  I don't recall any
> slab fixes post 2.3.33-mm1.  hm.
> 
> Questions, please: how much physical memory, how many CPUs?

8 CPU PIII-700
16 GB physical ram


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Ed Tomlinson]

On September 3, 2002 09:13 pm, Andrew Morton wrote:
> ext3_inode_cache     959   2430    448  264  270    1
>
> That's 264 pages in use, 270 total.  If there's a persistent gap between
> these then there is a problem - could well be that slablru is not locating
> the pages which were liberated by the pruning sufficiently quickly.

Sufficiently quickly is a relative thing.  It could also be that by the time
the pages are reclaimed another <n> have been cleaned.  IMO its no worst
than have freeable pages on lru from any other source.  If we get close to
oom we will call kmem_cache_reap, otherwise we let the lru find the pages.

> Calling kmem_cache_reap() after running the pruners will fix that up.

more specificly kmem_cache_reap will clean the one cache with the most
free pages...

>What on earth is going on with kmem_cache_reap?  Am I missing
>something, or is that thing 700% overdesigned?  Why not just
>free the darn pages in kmem_cache_free_one()?  Maybe hang onto
>a few pages for cache warmth, but heck.

This might be as simple as we can see the free pages in slabs.  We
cannot see other freeable pages in the lru.  This makes slabs seem
like a problem - just because we can see it.

On the other hand we could setup to call __kmem_cache_shrink_locked
after pruning a cache - as it is now this will use page_cache_release
to free the pages...  Need to be careful coding this though.

Andrew, you stated that we need to consider dcache and icache pages
as very important ones.  I submit that this is what slablru is doing.
It is keeping more of these objects around than the previous design,
which is what you wanted to see happen.

Still working on a good reply to your design suggestion/questions?

Ed

-------------------------------------------------------

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Andrew Morton]

Ed Tomlinson wrote:
> 
> On September 3, 2002 09:13 pm, Andrew Morton wrote:
> 
> > ext3_inode_cache     959   2430    448  264  270    1
> >
> > That's 264 pages in use, 270 total.  If there's a persistent gap between
> > these then there is a problem - could well be that slablru is not locating
> > the pages which were liberated by the pruning sufficiently quickly.
> 
> Sufficiently quickly is a relative thing.

Those pages are useless!  It's silly having slab hanging onto them
while we go and reclaim useful pagecache instead.

I *really* think we need to throw away those pages instantly.

The only possible reason for hanging onto them is because they're
cache-warm.  And we need a global-scope cpu-local hot pages queue
anyway.

And once we have that, slab _must_ release its warm pages into it.
It's counterproductive for slab to hang onto warm pages when, say,
a pagefault needs one.

>  It could also be that by the time the
> pages are reclaimed another <n> have been cleaned.  IMO its no worst than
> have freeable pages on lru from any other source.  If we get close to oom
> we will call kmem_cache_reap, otherwise we let the lru find the pages.

As I say, by not releasing those (useless to slab) pages, we're causing
other (useful) stuff to be reclaimed.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Stephen C. Tweedie]

Hi,

On Tue, Sep 03, 2002 at 08:33:37PM -0700, Andrew Morton wrote:

> I *really* think we need to throw away those pages instantly.
> 
> The only possible reason for hanging onto them is because they're
> cache-warm.  And we need a global-scope cpu-local hot pages queue
> anyway.

Yep --- except for caches with constructors, for which we do save a
bit more by hanging onto the pages for longer.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Andrew Morton]

"Stephen C. Tweedie" wrote:
> 
> Hi,
> 
> On Tue, Sep 03, 2002 at 08:33:37PM -0700, Andrew Morton wrote:
> 
> > I *really* think we need to throw away those pages instantly.
> >
> > The only possible reason for hanging onto them is because they're
> > cache-warm.  And we need a global-scope cpu-local hot pages queue
> > anyway.
> 
> Yep --- except for caches with constructors, for which we do save a
> bit more by hanging onto the pages for longer.

Ah, of course.  Thanks.

We'll still have a significant volume of pre-constructed objects
in the partially-full slabs: it seems that these things are fairly
prone to internal fragmentation, which works to our advantage in
this case.

So yes, perhaps we need to hang onto some preconstructed pages
for these slabs, if the internal fragmentation of the existing
part-filled slabs is low.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

2.5.33-mm1

[Andrew Morton]

Seven new patches - mostly just code cleanups.

+slablru-speedup.patch

  A patch to improve slablru cpu efficiency.  Ed is
  redoing this.

+oom-fix.patch

  Fix an OOM-killing episode on large highmem machines.

+tlb-cleanup.patch

  Remove debug code from the tlb_gather rework, tidy up a couple of
  things.

+dump-stack.patch

  Arch-independent stack-dumping debug function

+madvise-move.patch

  Move the madvise implementation out of filemap.c into madvise.c

+split-vma.patch

  Rationalise lots of the VMA-manipulation code.

+buffer-ops-move.patch

  Move the buffer_head IO functions out of ll_rw_blk.c, into buffer.c




scsi_hack.patch
  Fix block-highmem for scsi

ext3-htree.patch
  Indexed directories for ext3

rmap-locking-move.patch
  move rmap locking inlines into their own header file.

discontig-paddr_to_pfn.patch
  Convert page pointers into pfns for i386 NUMA

discontig-setup_arch.patch
  Rework setup_arch() for i386 NUMA

discontig-mem_init.patch
  Restructure mem_init for i386 NUMA

discontig-i386-numa.patch
  discontigmem support for i386 NUMA

cleanup-mem_map-1.patch
  Clean up lots of open-coded uese of mem_map[].  For ia32 NUMA

zone-pages-reporting.patch
  Fix the boot-time reporting of each zone's available pages

enospc-recovery-fix.patch
  Fix the __block_write_full_page() error path.

fix-faults.patch
  Back out the initial work for atomic copy_*_user()

spin-lock-check.patch
  spinlock/rwlock checking infrastructure

refill-rate.patch
  refill the inactive list more quickly

copy_user_atomic.patch

kmap_atomic_reads.patch
  Use kmap_atomic() for generic_file_read()

kmap_atomic_writes.patch
  Use kmap_atomic() for generic_file_write()

throttling-fix.patch
  Fix throttling of heavy write()rs.

dirty-state-accounting.patch
  Make the global dirty memory accounting more accurate

rd-cleanup.patch
  Cleanup and fix the ramdisk driver (doesn't work right yet)

discontig-cleanup-1.patch
  i386 discontigmem coding cleanups

discontig-cleanup-2.patch
  i386 discontigmem cleanups

writeback-thresholds.patch
  Downward adjustments to the default dirtymemory thresholds

buffer-strip.patch
  Limit the consumption of ZONE_NORMAL by buffer_heads

rmap-speedup.patch
  rmap pte_chain space and CPU reductions

wli-highpte.patch
  Resurrect CONFIG_HIGHPTE - ia32 pagetables in highmem

readv-writev.patch
  O_DIRECT support for readv/writev

slablru.patch
  age slab pages on the LRU

slablru-speedup.patch
  slablru optimisations

llzpr.patch
  Reduce scheduling latency across zap_page_range

buffermem.patch
  Resurrect buffermem accounting

config-PAGE_OFFSET.patch
  Configurable kenrel/user memory split

lpp.patch
  ia32 huge tlb pages

ext3-sb.patch
  u.ext3_sb -> generic_sbp

oom-fix.patch
  Fix an OOM condition on big highmem machines

tlb-cleanup.patch
  Clean up the tlb gather code

dump-stack.patch
  arch-neutral dump_stack() function

madvise-move.patch
  move mdavise implementation into mm/madvise.c

split-vma.patch
  VMA splitting patch

buffer-ops-move.patch
  Move submit_bh() and ll_rw_block() into fs/buffer.c
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[William Lee Irwin III]

On Mon, Sep 02, 2002 at 09:16:44PM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.33/2.5.33-mm1/
> Seven new patches - mostly just code cleanups.
> +slablru-speedup.patch
>   A patch to improve slablru cpu efficiency.  Ed is
>   redoing this.

count_list() appears to be the largest consumer of cpu after this is
done, or so say the profiles after running updatedb by hand on
2.5.33-mm1 on a 900MHz P-III T21 Thinkpad with 256MB of RAM.

  4608 __rdtsc_delay                            164.5714
  2627 __generic_copy_to_user                    36.4861
  2401 count_list                                42.8750
  1415 find_inode_fast                           29.4792
  1325 do_anonymous_page                          3.3801

It also looks like there's either a bit of internal fragmentation or a
missing kmem_cache_reap() somewhere:

  ext3_inode_cache:    20001KB    51317KB   38.97
      dentry_cache:     4734KB    18551KB   25.52
   radix_tree_node:     1811KB     1923KB   94.20
       buffer_head:     1132KB     1378KB   82.12

It does stay quite a bit more nicely bounded than without slablru though.

Maybe it's old news. Just thought I'd try running a test on something tiny
for once. (new kbd/mouse config options were a PITA BTW)


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Rik van Riel]

On Tue, 3 Sep 2002, William Lee Irwin III wrote:

> count_list() appears to be the largest consumer of cpu after this is
> done, or so say the profiles after running updatedb by hand on
> 2.5.33-mm1 on a 900MHz P-III T21 Thinkpad with 256MB of RAM.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Maybe it's old news. Just thought I'd try running a test on something
> tiny for once. (new kbd/mouse config options were a PITA BTW)

You've got an interesting idea of tiny ;)

Somehow I have the idea that the Linux users with 64 MB
of RAM or less have _more_ memory together than what's
present in all the >8GB Linux servers together...

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Andrew Morton]

William Lee Irwin III wrote:
> 
> On Mon, Sep 02, 2002 at 09:16:44PM -0700, Andrew Morton wrote:
> > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.33/2.5.33-mm1/
> > Seven new patches - mostly just code cleanups.
> > +slablru-speedup.patch
> >   A patch to improve slablru cpu efficiency.  Ed is
> >   redoing this.
> 
> count_list() appears to be the largest consumer of cpu after this is
> done, or so say the profiles after running updatedb by hand on
> 2.5.33-mm1 on a 900MHz P-III T21 Thinkpad with 256MB of RAM.

That's my /proc/meminfo:buffermem counter-upper.  I said it would suck ;)
Probably count_list(&inode_unused) can just be nuked.  I don't think blockdev
inodes ever go onto inode_unused.

>   4608 __rdtsc_delay                            164.5714
>   2627 __generic_copy_to_user                    36.4861
>   2401 count_list                                42.8750
>   1415 find_inode_fast                           29.4792
>   1325 do_anonymous_page                          3.3801
> 
> It also looks like there's either a bit of internal fragmentation or a
> missing kmem_cache_reap() somewhere:
> 
>   ext3_inode_cache:    20001KB    51317KB   38.97
>       dentry_cache:     4734KB    18551KB   25.52
>    radix_tree_node:     1811KB     1923KB   94.20
>        buffer_head:     1132KB     1378KB   82.12

That's really outside the control of slablru.  It's determined
by the cache-specific LRU algorithms, and the allocation order.

You'll need to look at the second-last and third-last columns in
/proc/slabinfo (boy I wish that thing had a heading line, or a nice
program to interpret it):

ext3_inode_cache     959   2430    448  264  270    1

That's 264 pages in use, 270 total.  If there's a persistent gap between
these then there is a problem - could well be that slablru is not locating
the pages which were liberated by the pruning sufficiently quickly.

Calling kmem_cache_reap() after running the pruners will fix that up.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[William Lee Irwin III]

William Lee Irwin III wrote:
>> It also looks like there's either a bit of internal fragmentation or a
>> missing kmem_cache_reap() somewhere:
>>   ext3_inode_cache:    20001KB    51317KB   38.97
>>       dentry_cache:     4734KB    18551KB   25.52
>>    radix_tree_node:     1811KB     1923KB   94.20
>>        buffer_head:     1132KB     1378KB   82.12

On Tue, Sep 03, 2002 at 06:13:17PM -0700, Andrew Morton wrote:
> That's really outside the control of slablru.  It's determined
> by the cache-specific LRU algorithms, and the allocation order.
> You'll need to look at the second-last and third-last columns in
> /proc/slabinfo (boy I wish that thing had a heading line, or a nice
> program to interpret it):
> ext3_inode_cache     959   2430    448  264  270    1
> That's 264 pages in use, 270 total.  If there's a persistent gap between
> these then there is a problem - could well be that slablru is not locating
> the pages which were liberated by the pruning sufficiently quickly.
> Calling kmem_cache_reap() after running the pruners will fix that up.

# grep ext3_inode_cache /proc/slabinfo 
ext3_inode_cache   18917  87012    448 7686 9668    1
...
ext3_inode_cache:     8098KB    38052KB   21.28

Looks like a persistent gap from here.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Andrew Morton]

William Lee Irwin III wrote:
> 
> ...
> > Calling kmem_cache_reap() after running the pruners will fix that up.
> 
> # grep ext3_inode_cache /proc/slabinfo
> ext3_inode_cache   18917  87012    448 7686 9668    1
> ...
> ext3_inode_cache:     8098KB    38052KB   21.28
> 
> Looks like a persistent gap from here.

OK, thanks.  We need to reap those pages up-front rather than waiting
for them to come to the tail of the LRU.

What on earth is going on with kmem_cache_reap?  Am I missing
something, or is that thing 700% overdesigned?  Why not just
free the darn pages in kmem_cache_free_one()?  Maybe hang onto
a few pages for cache warmth, but heck.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[Ed Tomlinson]

On September 3, 2002 09:15 pm, William Lee Irwin III wrote:
> William Lee Irwin III <wli@holomorphy.com>

What are the numbers telling you?  Is you test faster or slower
with slablru?  Does it page more or less?  Is looking at the number
of objects the way to determine if slablru is helping?  I submit
the paging and runtimes are much better indications?  What do
story do they tell?

Thanks
Ed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: 2.5.33-mm1

[William Lee Irwin III]

On September 3, 2002 09:15 pm, William Lee Irwin III wrote:
>> William Lee Irwin III <wli@holomorphy.com>
[something must have gotten snipped]

On Tue, Sep 03, 2002 at 10:55:43PM -0400, Ed Tomlinson wrote:
> What are the numbers telling you?  Is you test faster or slower
> with slablru?  Does it page more or less?  Is looking at the number
> of objects the way to determine if slablru is helping?  I submit
> the paging and runtimes are much better indications?  What do
> story do they tell?

Everything else is pretty much fine-tuning. Prior to this there was
zero control exerted over the things. Now it's much better behaved
with far less "swapping while buttloads of instantly reclaimable slab
memory is available" going on. Almost no swapping out of user memory
in favor of bloated slabs.

It's really that binary distinction that's most visible.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/