Re: Cached memory never gets released

From: David Ashley (dash_at_xdr.com)
Date: 06/29/04

  • Next message: Dave Jones: "Re: [PATCH 2.6.7-mm3] cpuflags reviewed" 
    Date:	Tue, 29 Jun 2004 08:07:23 -0700
To: linux-kernel@vger.kernel.org

    More developments:

    I've removed the ramdisk + nfs elements for testing. Now the system
    has the root filesystem on /dev/hda1 (normal ide hard drive). This makes
    no difference, the cache memory still builds up.

    I got the SysRq stuff working, here are 3 successive snapshots with
    progressively more memory lost to the cache:

    SysRq : Show Memory
    Mem-info:
    Free pages: 73804kB ( 0kB HighMem)
    Zone:DMA freepages: 14008kB
    Zone:Normal freepages: 59796kB
    Zone:HighMem freepages: 0kB
    ( Active: 3146, inactive: 5217, free: 18451 )
    6*4kB 6*8kB 5*16kB 5*32kB 4*64kB 9*128kB 6*256kB 3*512kB 3*1024kB 3*2048kB = 14008kB)
    1231*4kB 881*8kB 565*16kB 262*32kB 103*64kB 28*128kB 5*256kB 1*512kB 0*1024kB 9*2048kB = 59796kB)
    = 0kB)
    Swap cache: add 0, delete 0, find 0/0, race 0+0
    Free swap: 0kB
    28672 pages of RAM
    0 pages of HIGHMEM
    901 reserved pages
    4863 pages shared
    0 pages swap cached
    18 pages in page table cache
    Buffer memory: 80kB
    Cache memory: 11680kB

    SysRq : Show Memory
    Mem-info:
    Free pages: 67912kB ( 0kB HighMem)
    Zone:DMA freepages: 13768kB
    Zone:Normal freepages: 54144kB
    Zone:HighMem freepages: 0kB
    ( Active: 4005, inactive: 5837, free: 16978 )
    34*4kB 30*8kB 25*16kB 28*32kB 27*64kB 23*128kB 11*256kB 7*512kB 1*1024kB 0*2048kB = 13768kB)
    422*4kB 807*8kB 315*16kB 272*32kB 190*64kB 73*128kB 20*256kB 7*512kB 2*1024kB 0*2048kB = 54144kB)
    = 0kB)
    Swap cache: add 0, delete 0, find 0/0, race 0+0
    Free swap: 0kB
    28672 pages of RAM
    0 pages of HIGHMEM
    901 reserved pages
    1324 pages shared
    0 pages swap cached
    34 pages in page table cache
    Buffer memory: 76kB
    Cache memory: 17440kB

    SysRq : Show Memory
    Mem-info:
    Free pages: 67700kB ( 0kB HighMem)
    Zone:DMA freepages: 14012kB
    Zone:Normal freepages: 53688kB
    Zone:HighMem freepages: 0kB
    ( Active: 9181, inactive: 874, free: 16925 )
    5*4kB 5*8kB 4*16kB 4*32kB 3*64kB 8*128kB 5*256kB 2*512kB 2*1024kB 4*2048kB = 14012kB)
    584*4kB 819*8kB 644*16kB 334*32kB 182*64kB 45*128kB 15*256kB 5*512kB 0*1024kB 0*2048kB = 53688kB)
    = 0kB)
    Swap cache: add 0, delete 0, find 0/0, race 0+0
    Free swap: 0kB
    28672 pages of RAM
    0 pages of HIGHMEM
    901 reserved pages
    256 pages shared
    0 pages swap cached
    48 pages in page table cache
    Buffer memory: 44kB
    Cache memory: 38396kB

    This problem is almost certainly within the linux kernel. It is very
    difficult to reproduce since you've got to have
    1) XFree86
    2) Mozilla browser
    3) Macromedia flash plugin
    4) A certain flash page, not just any will do

    Constantly reloading the flash page results in the cache buildup.
    This represents a great denial of service opportunity if someone could
    reduce this to the essence of how to make the problem happen.

    Recently there was the announcement of the problem where if you get a
    floating point exception within a signal handler repeatedly you could cause
    the kernel to break. Perhaps this is a similiar situation, maybe if you
    free a page within a signal handler, or unmap it, or something? I'm really
    grasping here.

    Note this is 2.4.x series kernel. I've tried 2.4.23 and 2.4.26. We've got a
    modified kernel but going back to stock 2.4.26 with no custom modules has
    the same problem. Usually the root filesystem is a 2M ramdisk with symlinks
    to a readonly NFS mountpoint, but as stated above I tried replacing this with
    a typical /dev/hda1 root filesystem with no change in behaviour.

    Someone throw me a bone. I think I've been following up on everyone's
    suggestions pretty well. I need ideas.

    Thanks--
    Dave
    -
    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/

  • Next message: Dave Jones: "Re: [PATCH 2.6.7-mm3] cpuflags reviewed"

    Relevant Pages

    • Re: Cached memory never gets released
      ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
      (Linux-Kernel)
    • Re: Problem: Creating a raw binary string
      ... > While its true that a 64-bit cpu will move twice the data per instruction it ... > Memory bus width plays an important role here and unless it too is widened / ... You are forgetting the two levels of cache in the processor. ... The memory chips are addressed in Row col fashion. ...
      (alt.comp.lang.borland-delphi)
    • Re: Is Greenspun enough?
      ... Most OSes memory map executables directly from the file system so code doesn't pollute the file cache or swap space. ...
      (comp.lang.lisp)
    • Re: Superstitious learning in Computer Architecture
      ... Without a LOT of logic or some other better approach, re-executing the instructions requires re-decoding and it ties up the cache memory bus transferring more data as instructions than the instructions are working on. ... The concept of cache is fundamentally flawed in that it STILL restricts access to one word per clock cycle, when a single modern ALU can easily use 5 plus whatever is eaten up with instruction accesses. ... The size of an optimizing compiler is proportional to the SQUARE of the size of the language times the SQUARE of the complexity of the machine - because all interactions must be considered. ...
      (comp.arch.arithmetic)
    • Re: FPGA-based hardware accelerator for PC
      ... I know that in most cases the CPU ... that it contsins no cache, as BRAMs are too precious resources to be wasted ... The BRAMs are what define the opportunity, ... many threads with full associativity of memory lines using hashed MMU ...
      (comp.arch.fpga)