On Tue 10-09-19 09:03:29, Tejun Heo wrote: > Hello, Michal. > > On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote: > > > So, while it'd great to have shrinkers in the longer term, it's not a > > > strict requirement to be accounted in memcg. It already accounts a > > > lot of memory which isn't reclaimable (a lot of slabs and socket > > > buffer). > > > > Yeah, having a shrinker is preferred but the memory should better be > > reclaimable in some form. If not by any other means then at least bound > > to a user process context so that it goes away with a task being killed > > by the OOM killer. If that is not the case then we cannot really charge > > it because then the memcg controller is of no use. We can tolerate it to > > some degree if the amount of memory charged like that is negligible to > > the overall size. But from the discussion it seems that these buffers > > are really large. > > Yeah, oom kills should be able to reduce the usage; however, please > note that tmpfs, among other things, can already escape this > restriction and we can have cgroups which are over max and empty. > It's obviously not ideal but the system doesn't melt down from it > either. Right, and that is a reason why an access to tmpfs should be restricted when containing a workload by memcg. My understanding of this particular feature is that memcg should be the primary containment method and that's why I brought this up. -- Michal Hocko SUSE Labs _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
