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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
