On Tue 31-08-21 16:38:05, Feng Tang wrote: > There was report that starting an Ubuntu in docker while using cpuset > to bind it to movlabe nodes (a node only has movable zone, like a node > for hotplug or a PMEM node in normal usage) will fail due to memory > allocation failure, and then OOM is involved and many other innocent > processes got killed. It can be reproduced with command: > $docker run -it --rm --cpuset-mems 4 ubuntu:latest bash -c > "grep Mems_allowed /proc/self/status" (node 4 is a movable node) Is there any valid usecase to allow cpusets to be configured only to movable nodes? Wouldn't it be better to simply disallow such a setup? I do understand that we usually allow people to shoot their feet but this one has some wider consequences. > The reason is, in the case, the target cpuset nodes only have movable > zone, while the creation of an OS in docker sometimes needs to allocate > memory in non-movable zones (dma/dma32/normal) like GFP_HIGHUSER, and > the cpuset limit forbids the allocation, then out-of-memory killing is > involved even when normal nodes and movable nodes both have many free > memory. > > We've posted patches to LKML trying to make the usage working by > loosening the check, which is not agreed as the cpuset binding should > be respected, and should not be bypassed [1] > > But still there is another problem, that when the usage fails as it's an > mission impossible due to the cpuset limit, the allocating should just > be killed first, before any other innocent processes get killed. I do not like this solution TBH. We know that that it is impossible to satisfy the allocation at the page allocator level so dealing with it at the OOM killer level is just a bad layering and a lot of wasted cycles to reach that point. Why cannot we simply fail the allocation if cpusets filtering leads to an empty zone intersection? -- Michal Hocko SUSE Labs
