lkml.org 
[lkml]   [2011]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [BUG] fatal hang untarring 90GB file, possibly writeback related.
    From
    Date
    On Fri, 2011-04-29 at 13:02 -0500, James Bottomley wrote:
    > On Fri, 2011-04-29 at 11:31 -0500, James Bottomley wrote:
    > > On Fri, 2011-04-29 at 10:37 -0500, James Bottomley wrote:
    > > > On Fri, 2011-04-29 at 12:23 +0200, Sedat Dilek wrote:
    > > > > But as I see these RCU (CPU) stalls, the patch from [1] might be worth a try.
    > > > > First, I have seen negative effects on my UP-system was when playing
    > > > > with linux-next [2].
    > > > > It was not clear what the origin was and the the side-effects were
    > > > > somehow "bizarre".
    > > > > The issue could be easily reproduced by tar-ing the kernel build-dir
    > > > > to an external USB-hdd.
    > > > > The issue kept RCU and TIP folks really busy.
    > > > > Before stepping 4 weeks in the dark, give it a try and let me know in
    > > > > case of success.
    > > >
    > > > Well, it's highly unlikely because that's a 2.6.39 artifact and the bug
    > > > showed up in 2.6.38 ... I tried it just in case with no effect, so we
    > > > know it isn't the cause.
    > >
    > > Actually, I tell a lie: it does't stop kswapd spinning on PREEMPT, but
    > > it does seem to prevent non-PREEMPT from locking up totally (at least it
    > > survives three back to back untar runs).
    > >
    > > It's probable it alters the memory pin conditions that cause the spin,
    > > so it's masking the problem rather than fixing it.
    >
    > Confirmed ... it's just harder to reproduce with the hrtimers init fix.
    > The problem definitely still exists (I had to load up the system more
    > before doing the tar).
    >
    > This time I've caught kswapd in mem_cgroup_shrink_node_zone. sysrq-w
    > doesn't complete for an unknown reason

    As a follow on to this, there's a shrink_zone(0, ...) in the cgroup
    path. This causes it to scan all memory exhaustively (generating quite
    a lot of work). The comment above it implies it's some type of hack for
    cgroup accounting, but reducing it to DEF_PRIORITY makes the hang go
    away (verified on both 2.6.39-rc4 and 2.6.38.4). Note that I still get
    soft lockups in kswapd0, but they no longer hang the box. I'll prepare
    a patch for the next round of debate.

    James




    \
     
     \ /
      Last update: 2011-05-02 22:07    [W:9.320 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site