On Fri, Mar 11, 2016 at 02:39:36PM +0100, Michal Hocko wrote: > On Fri 11-03-16 14:49:34, Vladimir Davydov wrote: > > On Fri, Mar 11, 2016 at 10:53:09AM +0100, Michal Hocko wrote: > > > > OTOH memory.low and memory.high are perfect to be changed dynamically, > > > > basing on containers' memory demand/pressure. A load manager might want > > > > to reconfigure these knobs say every 5 seconds. Spawning a thread per > > > > each container that often would look unnecessarily overcomplicated IMO. > > > > > > The question however is whether we want to hide a potentially costly > > > operation and have it unaccounted and hidden in the kworker context. > > > > There's already mem_cgroup->high_work doing reclaim in an unaccounted > > context quite often if tcp accounting is enabled. > > I suspect this is done because the charging context cannot do much > better. > > > And there's kswapd. > > memory.high knob is for the root only so it can't be abused by an > > unprivileged user. Regarding a privileged user, e.g. load manager, it > > can screw things up anyway, e.g. by configuring sum of memory.low to be > > greater than total RAM on the host and hence driving kswapd mad. > > I am not worried about abuse. It is just weird to move something which > can be perfectly sync to an async mode. > > > > I mean fork() + write() doesn't sound terribly complicated to me to have > > > a rather subtle behavior in the kernel. > > > > It'd be just a dubious API IMHO. With memory.max everything's clear: it > > tries to reclaim memory hard, may stall for several seconds, may invoke > > OOM, but if it finishes successfully we have memory.current less than > > memory.max. With this patch memory.high knob behaves rather strangely: > > it might stall, but there's no guarantee you'll have memory.current less > > than memory.high; moreover, according to the documentation it's OK to > > have memory.current greater than memory.high, so what's the point in > > calling synchronous reclaim blocking the caller? > > Even if the reclaim is best effort it doesn't mean we should hide it > into an async context. There is simply no reason to do so. We do the > some for other knobs which are performing a potentially expensive > operation and do not guarantee the result. IMO it depends on what a knob is used for. If it's for testing or debugging or recovering the system (e.g. manual oom, compact, drop_caches), this must be synchronous, but memory.high is going to be tweaked at runtime during normal system operation every several seconds or so, at least in my understanding. I understand your concern, and may be you're right in the end, but think about userspace that will probably have to spawn thousands threads every 5 seconds or so just to write to a file. It's painful IMO. Are there any hidden non-obvious implications of handing over reclaim to a kernel worker on adjusting memory.high? May be, I'm just missing something obvious, and it can be really dangerous or sub-optimal. Thanks, Vladimir -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>