On Wed 10-08-11 08:54:37, KAMEZAWA Hiroyuki wrote: > On Tue, 9 Aug 2011 13:46:42 +0200 > Michal Hocko <mhocko@xxxxxxx> wrote: > > > On Tue 09-08-11 19:07:25, KAMEZAWA Hiroyuki wrote: > > > On Tue, 9 Aug 2011 12:09:44 +0200 > > > Michal Hocko <mhocko@xxxxxxx> wrote: > > > > > > > On Tue 09-08-11 18:53:13, KAMEZAWA Hiroyuki wrote: > > > > > On Tue, 9 Aug 2011 11:45:03 +0200 > > > > > Michal Hocko <mhocko@xxxxxxx> wrote: > > > > > > > > > > > On Tue 09-08-11 18:32:16, KAMEZAWA Hiroyuki wrote: > > > > > > > On Tue, 9 Aug 2011 11:31:50 +0200 > > > > > > > Michal Hocko <mhocko@xxxxxxx> wrote: > > > > > > > > > > > > > > > What do you think about the half backed patch bellow? I didn't manage to > > > > > > > > test it yet but I guess it should help. I hate asymmetry of drain_lock > > > > > > > > locking (it is acquired somewhere else than it is released which is > > > > > > > > not). I will think about a nicer way how to do it. > > > > > > > > Maybe I should also split the rcu part in a separate patch. > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > > I'd like to revert 8521fc50 first and consider total design change > > > > > > > rather than ad-hoc fix. > > > > > > > > > > > > Agreed. Revert should go into 3.0 stable as well. Although the global > > > > > > mutex is buggy we have that behavior for a long time without any reports. > > > > > > We should address it but it can wait for 3.2. > > > > > > > > I will send the revert request to Linus. > > > > > > > > > What "buggy" means here ? "problematic" or "cause OOps ?" > > > > > > > > I have described that in an earlier email. Consider pathological case > > > > when CPU0 wants to async. drain a memcg which has a lot of cached charges while > > > > CPU1 is already draining so it holds the mutex. CPU0 backs off so it has > > > > to reclaim although we could prevent from it by getting rid of cached > > > > charges. This is not critical though. > > > > > > > > > > That problem should be fixed by background reclaim. > > > > How? Do you plan to rework locking or the charge caching completely? > > > > From your description, the problem is not the lock itself but a task > may go into _unnecessary_ direct-reclaim even if there are remaining > chages on per-cpu stocks, which cause latency. The problem is partly the lock because it prevents from parallel async reclaimers. This is too restrictive. If we are going to rely on async draining we will have to above problem. > > In (all) my automatic background reclaim tests, no direct reclaim happens > if background reclaim is enabled. Yes, I haven't seen this problem yet but I guess that there is non 0 chance that there is a workload which triggers this. > And as I said before, we may be able to add a flag not to cache > more. It's set by some condition ....as usage is near to the limit. > > Thanks, > -Kame Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>