Hello, Shakeel. On Wed, Dec 20, 2017 at 12:15:46PM -0800, Shakeel Butt wrote: > > I don't understand how this invariant is useful across different > > backing swap devices and availability. e.g. Our OOM decisions are > > currently not great in that the kernel can easily thrash for a very > > long time without making actual progresses. If you combine that with > > widely varying types and availability of swaps, > > The kernel never swaps out on hitting memsw limit. So, the varying > types and availability of swaps becomes invariant to the memcg OOM > behavior of the job. The kernel doesn't swap because of memsw because that wouldn't change the memsw number; however, that has nothing to do with whether the underlying swap device affects OOM behavior or not. That invariant can't prevent memcg decisions from being affected by the performance of the underlying swap device. How could it possibly achieve that? The only reason memsw was designed the way it was designed was to avoid lower swap limit meaning more memory consumption. It is true that swap and memory consumptions are interlinked; however, so are memory and io, and we can't solve these issues by interlinking separate resources in a single resource knob and that's why they're separate in cgroup2. > > Sure, but what does memswap achieve? > > 1. memswap provides consistent memcg OOM killer and memcg memory > reclaim behavior independent to swap. > 2. With memswap, the job owners do not have to think or worry about swaps. To me, you sound massively confused on what memsw can do. It could be that I'm just not understanding what you're saying. So, let's try this one more time. Can you please give one concrete example of memsw achieving critical capabilities that aren't possible without it? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
