[lkml]   [2008]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: BUG: drop_pagecache_sb vs kjournald lockup
    On Tue, Mar 18, 2008 at 02:43:26PM +0100, Jan Kara wrote:
    > > 2.6.25-rc3, 4p ia64, ext3 root drive.
    > >
    > > I was running an XFS stress test on one of the XFS partitions on
    > > the machine (zero load on the root ext3 drive), when the system
    > > locked up in kjournald with this on the console:
    > >
    > > BUG: spinlock lockup on CPU#2, kjournald/2150, a000000100e022e0
    > >
    > <snip traces>

    <snip other stuff>

    > > Anyone know the reason why drop_pagecache_sb() uses such a brute-force
    > > mechanism to free up clean page cache pages?
    > Yes, we know that drop_pagecache_sb() has locking issues but since it
    > is intended to be used for debugging purposes only, nobody cared enough
    > to fix it. Completely untested patch below if you dare to try ;)

    It may be intended for debuging purposes, but it does get used in
    production HPC environments (a lot!). I guess I've never seen this
    lockup before because SGI customers don't use ext3, but they have
    complained about the system "stopping" while drop_caches is executed.
    This locking ..... strategy would explain it, though.

    I'll try the patch, but I can't guarantee anything - I only saw this
    lockup once in about 18 hours when dropping caches every 2 seconds.


    Dave Chinner
    Principal Engineer
    SGI Australian Software Group

     \ /
      Last update: 2008-03-19 21:33    [W:0.020 / U:5.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site