On Tue, Apr 07, 2020 at 01:10:17PM +0200, Michal Hocko wrote:
> On Tue 07-04-20 17:31:33, Yafang Shao wrote:
> > I checked the explaination about ENOSPC in 73f576c04b94 ("mm:
> > memcontrol: fix cgroup creation failure after many small jobs")
> > carefully, but I don't a clear idea which one is better now.
>
> The changelog simply mentioned that without the additional id tracking
> the ENOSPC would have been returned from elsewhere. I haven't checked
> but I suspect it would be from the cgroup core. This patch just didn't
> propagate the idr failure specifically and hid it under the ENOMEM
> failure path. I can only speculate why that was the case but I suspect
> that Johannes simply didn't consider the distinction important enough.
The old -ENOSPC came directly from the memcg css online callback:
- if (css->id > MEM_CGROUP_ID_MAX)
- return -ENOSPC;
And it only became a problem because, on big memory machines (128+G)
with a high rate of short-lived jobs, lazily freed cgroups piled up
over the course of multiple days and clogged up the ID space. Nobody
actually tried to create 64k user-visible cgroups concurrently. It's
hard to imagine any machine running that many meaningfully distinct
memory consumers in parallel. So I didn't think (and still don't tbh)
it matters all that much in practice what we return here.
I'm not against changing it back to -ENOSPC. And I agree with Michal
it might be better than -EBUSY because of the mkdir() interface.
Given how unlikely this is to affect real setups, I don't think this
patch is stable material.
