![]() | |||||||||||||
Messages in this thread |
On Wed, Mar 5, 2008 at 11:37 AM, Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote: > list_del corruption in cgroup_exit() on 16 cpu, 32GB ia64 NUMA platform. > > I've been seeing this for a while now, but we've had known problems > [page leaks, ...] with the VM scalability series. Now the system > appears to be running very well with these patches under stress loads > that would hang it or cause OOM kill of tests with plenty of swap space > left. Eventually, [after 40-45 minutes], I hit a list corruption in > cgroup_exit(). > > I can't say for sure that our patches aren't causing this, but I've been > unable to keep the system up long enough under the stress load w/o the > splitlru+noreclaim patches to hit the problem. > > I looked in the mailing lists and found one other thread related to > cgroup list corruption: > > http://marc.info/?l=linux-kernel&m=119263666823236&w=4 > > Paul looked into this and couldn't see anywhere that the lists are > manipulate w/o holding the css set lock. I concur. I did find one > possible race in enabling the task cg_lists [see patch below], but this > did not solve the problem. And I did not hit the printk in the patch. No, that's not a (malign) race - cgroup_enable_task_cg_lists() is idempotent. In the case that you see, every thread seen in the do_each_thread() loop will already have a non-empty cg_list field, so it will be a no-op. So adding the additional check isn't wrong but it's not needed. I'll look again at the code to try to figure out where the problem is. Paul | ||||||||||||
| Last update: 2008-03-05 22:11 [from the cache] ©2003-2008 | |||||||||||||