[Sorry for jumping in so late - I've been busy last days] On Wed 27-08-14 16:36:44, Mel Gorman wrote: > On Tue, Aug 26, 2014 at 08:00:20PM -0400, Trond Myklebust wrote: > > On Tue, Aug 26, 2014 at 7:51 PM, Trond Myklebust > > <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > > On Tue, Aug 26, 2014 at 7:19 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: [...] > > >> wait_on_page_writeback() is a hammer, and we need to be better about > > >> this once we have per-memcg dirty writeback and throttling, but I > > >> think that really misses the point. Even if memcg writeback waiting > > >> were smarter, any length of time spent waiting for yourself to make > > >> progress is absurd. We just shouldn't be solving deadlock scenarios > > >> through arbitrary timeouts on one side. If you can't wait for IO to > > >> finish, you shouldn't be passing __GFP_IO. Exactly! > > >> Can't you use mempools like the other IO paths? > > > > > > There is no way to pass any allocation flags at all to an operation > > > such as __sock_create() (which may be needed if the server > > > disconnects). So in general, the answer is no. > > > > > > > Actually, one question that should probably be raised before anything > > else: is it at all possible for a workqueue like rpciod to have a > > non-trivial setting for ->target_mem_cgroup? If not, then the whole > > question is moot. > > AFAIK, today it's not possible to add kernel threads (which rpciod is one) > to a memcg so the issue is entirely theoritical at the moment. Even if > this was to change, it's not clear to me what adding kernel threads to a > memcg would mean as kernel threads have no RSS. Even if kernel resources > were accounted for, I cannot see why a kernel thread would join a memcg. It doesn't make _any_ sense to assign kernel threads to memcg as they do not have mm_struct associated with them and mm_struct is the central association point to memcg. I do not see any reason this to change in the future. > I expec that it's currently impossible for rpciod to have a non-trivial > target_mem_cgroup. The memcg folk will correct me if I'm wrong or if there > are plans to change that for some reason. The only possible case would be if the rpciod would use_mm of current for some reason. -- Michal Hocko SUSE Labs -- 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
