Re: Possible dcache BUG

[Gene Heskett]

On Thursday 12 August 2004 21:31, Linus Torvalds wrote:
>On Thu, 12 Aug 2004, Udo A. Steinberg wrote:
>> After nearly 2 days of running 2.6.8-rc4 with above patch backed
>> out, the machine has gone back into heavy swapping, being rather
>> unresponsive for several minutes. At that time the only bigger
>> applications running were X and my mailer, as can be seen in the
>> ps output below.
>
>Your slab usage seems to be:
>
>	cumulative	     usage	name
>	=========	    ======	====
>		.....
>	  2,021,428	   151,552	pgd
>	  2,182,804	   161,376	size-96
>	  2,367,124	   184,320	biovec-(256)
>	  2,559,124	   192,000	biovec-128
>	  2,751,124	   192,000	biovec-64
>	  2,997,076	   245,952	ext3_inode_cache
>	  3,255,124	   258,048	size-1024
>	  3,545,940	   290,816	size-512
>	  3,843,468	   297,528	radix_tree_node
>	  4,153,932	   310,464	inode_cache
>	  4,494,972	   341,040	dentry_cache
>	  4,994,684	   499,712	size-8192
>	  5,912,188	   917,504	size-32768
>	105,397,820	99,485,632	size-64
>
>Something pretty much stands out.
>
>What the _heck_ is doing 64-byte allocations and leaking them?
>
>Can you figure out what triggers it for you? If nothing obvious
> comes to mind, could you do something really silly like this
>
>	--- 1.141/mm/slab.c     2004-07-11 01:52:48 -07:00
>	+++ edited/mm/slab.c    2004-08-12 18:30:00 -07:00
>	@@ -2360,6 +2360,11 @@
>	                 */
>	                BUG_ON(csizep->cs_cachep == NULL);
>	 #endif
>	+               if (csizep->cs_size == 64) {
>	+                       static unsigned count;
>	+                       if (!(4095 & ++count))
>	+                               dump_stack();
>	+               }
>	                return __cache_alloc(flags & GFP_DMA ?
>	                         csizep->cs_dmacachep : csizep->cs_cachep,
> flags); }
>
>(totally whitespace-damaged) which should just print out a stack
> dump every four thoudand allocations, which should give a good clue
> (somebody else might also be allocating those 64-byte things, but
> _likely_ we'll see at least one of the leakers.. Maybe.)
>
>
>			Linus

I'm not seeing any of that here Linus.  Let me snip just the alloc sizes
of my current, up a bit over 24 hours, /proc/slabinfo

size-131072(DMA)       0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
size-131072            0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
size-65536(DMA)        0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
size-65536             1      1  65536    1   16 : tunables    8    4    0 : slabdata      1      1      0
size-32768(DMA)        0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
size-32768             0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
size-16384(DMA)        0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
size-16384             7      7  16384    1    4 : tunables    8    4    0 : slabdata      7      7      0
size-8192(DMA)         0      0   8192    1    2 : tunables    8    4    0 : slabdata      0      0      0
size-8192             10     10   8192    1    2 : tunables    8    4    0 : slabdata     10     10      0
size-4096(DMA)         0      0   4096    1    1 : tunables   24   12    0 : slabdata      0      0      0
size-4096            182    182   4096    1    1 : tunables   24   12    0 : slabdata    182    182      0
size-2048(DMA)         0      0   2048    2    1 : tunables   24   12    0 : slabdata      0      0      0
size-2048            170    198   2048    2    1 : tunables   24   12    0 : slabdata     99     99      0
size-1024(DMA)         0      0   1024    4    1 : tunables   54   27    0 : slabdata      0      0      0
size-1024            124    124   1024    4    1 : tunables   54   27    0 : slabdata     31     31      0
size-512(DMA)          0      0    512    8    1 : tunables   54   27    0 : slabdata      0      0      0
size-512             184    448    512    8    1 : tunables   54   27    0 : slabdata     56     56      0
size-256(DMA)          0      0    256   15    1 : tunables  120   60    0 : slabdata      0      0      0
size-256             165    450    256   15    1 : tunables  120   60    0 : slabdata     30     30      0
size-192(DMA)          0      0    192   20    1 : tunables  120   60    0 : slabdata      0      0      0
size-192             100    100    192   20    1 : tunables  120   60    0 : slabdata      5      5      0
size-128(DMA)          0      0    128   31    1 : tunables  120   60    0 : slabdata      0      0      0
size-128            1205   1271    128   31    1 : tunables  120   60    0 : slabdata     41     41      0
size-64(DMA)           0      0     64   61    1 : tunables  120   60    0 : slabdata      0      0      0
size-64             1850   2745     64   61    1 : tunables  120   60    0 : slabdata     45     45      0
size-32(DMA)           0      0     32  119    1 : tunables  120   60    0 : slabdata      0      0      0
size-32             1369   1428     32  119    1 : tunables  120   60    0 : slabdata     12     12      0
kmem_cache           124    124    128   31    1 : tunables  120   60    0 : slabdata      4      4      0

And I'm doing my usual activities here, browseing the web with mozilla,
handling the email with kmail from kde3.3-beta2, and watching a little
tv with tvtime or playing solitaire.

So far (knock on wood) its purring right along at about 80% of what
its normal speed would be, nothing unusual in the logs or in the top
display.  And it did 8 seti units in the last 24 before its 6am update,
part of which was on the unpatched kernel.  5 since 6am, its 22:00
here now.

Apparently Udo has something running I don't, and its a leaker.  Lets
hope your snooper patch will show it.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/