Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 3 Feb 2020 13:38:47 -0800
From:   Roman Gushchin <guro@fb.com>
To:     Johannes Weiner <hannes@cmpxchg.org>
CC:     Michal Hocko <mhocko@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Tejun Heo <tj@kernel.org>, <linux-mm@kvack.org>,
        <cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <kernel-team@fb.com>
Subject: Re: [PATCH v2 1/3] mm: memcontrol: fix memory.low proportional
 distribution
Message-ID: <20200203213847.GC6781@xps.dhcp.thefacebook.com>
References: <20191219200718.15696-1-hannes@cmpxchg.org>
 <20191219200718.15696-2-hannes@cmpxchg.org>
 <20200130114929.GT24244@dhcp22.suse.cz>
 <20200203212136.GC6380@cmpxchg.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200203212136.GC6380@cmpxchg.org>
MIME-Version: 1.0
Received-SPF: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
X-MS-Exchange-CrossTenant-Network-Message-Id: ac127476-1506-4da9-7091-08d7a8f17739
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2020 21:38:53.8871
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 87JvDyJNFQj2RGdRZD5JES4ip1OVaNRLPT19jShiCtab1CJE9Nu8RCGlplKYmnfK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3271
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572
 definitions=2020-02-03_07:2020-02-02,2020-02-03 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 impostorscore=0
 spamscore=0 suspectscore=2 mlxscore=0 mlxlogscore=858 lowpriorityscore=0
 malwarescore=0 phishscore=0 clxscore=1015 priorityscore=1501 adultscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-1911200001 definitions=main-2002030155
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 03, 2020 at 04:21:36PM -0500, Johannes Weiner wrote:
> On Thu, Jan 30, 2020 at 12:49:29PM +0100, Michal Hocko wrote:
> > On Thu 19-12-19 15:07:16, Johannes Weiner wrote:
> > > When memory.low is overcommitted - i.e. the children claim more
> > > protection than their shared ancestor grants them - the allowance is
> > > distributed in proportion to how much each sibling uses their own
> > > declared protection:
> > 
> > Has there ever been any actual explanation why do we care about
> > overcommitted protection? I have got back to email threads when
> > the effective hierarchical protection has been proposed.
> > http://lkml.kernel.org/r/20180320223353.5673-1-guro@fb.com talks about
> > some "leaf memory cgroups are more valuable than others" which sounds ok
> > but it doesn't explain why children have to overcommit parent in the
> > first place. Do we have any other documentation to explain the usecase?
> 
> I don't think we properly documented it, no. Maybe Roman can elaborate
> on that a bit more since he added it.

There is simple no way to prevent it. Cgroup v2 UI allows to set any values,
and they are never changed automatically on e.g. parent's value change.

So the system has to perform reasonably for all possible configurations.

Before introducing of effective protections it was way too defensive:
it was super easy to disable the protection by exceeding the protection
value on some level. So it wasn't possible to rely on it in production.

So disabling the protection in case of over-commitment isn't a good option
too.

Thanks!