On Wed 21-08-19 15:26:56, Yafang Shao wrote: > On Wed, Aug 21, 2019 at 2:44 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Wed 21-08-19 09:00:39, Yafang Shao wrote: > > [...] > > > More possible OOMs is also a strong side effect (and it prevent us > > > from using it). > > > > So why don't you use low limit if the guarantee side of min limit is too > > strong for you? > > Well, I don't know what the best-practice of memory.min is. It is really a workload reclaim protection. Say you have a memory consumer which performance characteristics would be noticeably disrupted by any memory reclaim which then would lead to SLA disruption. This is a strong requirement/QoS feature and as such comes with its demand on configuration. > In our plan, we want to use it to protect the top priority containers > (e.g. set the memory.min same with memory limit), which may latency > sensive. Using memory.min may sometimes decrease the refault. > If we set it too low, it may useless, becasue what memory.min is > protecting is not specified. And if there're some busrt anon memory > allocate in this memcg, the memory.min may can't protect any file > memory. I am still not seeing why you are considering guarantee (memory.min) rather than best practice (memory.low) here? -- Michal Hocko SUSE Labs
