lkml.org 
[lkml]   [2004]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Possible dcache BUG
    Date
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.030 / U:32.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site