On Fri, 16 Nov 2012, Glauber Costa wrote: > My personal take: > > Most people hate memcg due to the cost it imposes. I've already > demonstrated that with some effort, it doesn't necessarily have to be > so. (http://lwn.net/Articles/517634/) > > The one thing I missed on that work, was precisely notifications. If you > can come up with a good notifications scheme that *lives* in memcg, but > does not *depend* in the memcg infrastructure, I personally think it > could be a big win. > This doesn't allow users of cpusets without memcg to have an API for memory pressure, that's why I thought it should be a new cgroup that can be mounted alongside any existing cgroup, any cgroup in the future, or just by itself. > Doing this in memcg has the advantage that the "per-group" vs "global" > is automatically solved, since the root memcg is just another name for > "global". > That's true of any cgroup. > I honestly like your low/high/oom scheme better than memcg's > "threshold-in-bytes". I would also point out that those thresholds are > *far* from exact, due to the stock charging mechanism, and can be wrong > by as much as O(#cpus). So far, nobody complained. So in theory it > should be possible to convert memcg to low/high/oom, while still > accepting writes in bytes, that would be thrown in the closest bucket. > I'm wondering if we should have more than three different levels. > Another thing from one of your e-mails, that may shift you in the memcg > direction: > > "2. The last time I checked, cgroups memory controller did not (and I > guess still does not) not account kernel-owned slabs. I asked several > times why so, but nobody answered." > > It should, now, in the latest -mm, although it won't do per-group > reclaim (yet). > Not sure where that was written, but I certainly didn't write it and it's not really relevant in this discussion: memory pressure notifications would be triggered by reclaim when trying to allocate memory; why we need to reclaim or how we got into that state is tangential. It certainly may be because a lot of slab was allocated, but that's not the only case. > I am also failing to see how cpusets would be involved in here. I > understand that you may have free memory in terms of size, but still be > further restricted by cpuset. But I also think that having multiple > entry points for this buy us nothing at all. So the choices I see are: > Umm, why do users of cpusets not want to be able to trigger memory pressure notifications? -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
