From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E0A6E77197 for ; Tue, 7 Jan 2025 09:44:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC2D48D0006; Tue, 7 Jan 2025 04:44:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B72488D0001; Tue, 7 Jan 2025 04:44:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3A718D0006; Tue, 7 Jan 2025 04:44:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 867838D0001 for ; Tue, 7 Jan 2025 04:44:36 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0D6FC160808 for ; Tue, 7 Jan 2025 09:44:36 +0000 (UTC) X-FDA: 82980170952.22.9BC5154 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by imf29.hostedemail.com (Postfix) with ESMTP id 39544120004 for ; Tue, 7 Jan 2025 09:44:34 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HDG1Ntwv; spf=pass (imf29.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736243074; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hm2yrAqNGHJ1ITEnwyw6uBt6Rs3azdjCHMItr3g23Ks=; b=OqRAlgnzvFGiMHrnkQ8oj4ML7hhMhLn569M3wjcfH8Saw4tvA9+Eesvu6XBnMzNKu0JdOd 9F2Q8HNdi0MEDo3lexKIA45AcgfpSQbGrzc9WOMRtTKNHpj6UbKdDDcnjV7OjDa1C1dBCe CPO7qiAGtGfsQ7FMasOAxNjiQ+85/i0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HDG1Ntwv; spf=pass (imf29.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736243074; a=rsa-sha256; cv=none; b=qqM3/k0ByBdcp5Ejd++ND8S3Br0XmLsfiv+MsqlrejUbB+TfNN7iX+IMdzniLtG8S1bQI5 h6yKYKzOXAn3T8giCeqxPGQpBLIzkBzpS5AyOnbFHDRkzDYxeY06qSevFpqLqef+GtuB5S PCXyGYZlapjUJAmdQM4PPWqud+1DoYg= Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6d8a3e99e32so125094816d6.2 for ; Tue, 07 Jan 2025 01:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736243073; x=1736847873; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hm2yrAqNGHJ1ITEnwyw6uBt6Rs3azdjCHMItr3g23Ks=; b=HDG1NtwvmNwG/BHDDbdLj0XWpM+zfIBsb+2mk6Ao7ibI9GdjqeArEl9gHorzZz69wl xM8oRyaJtMgCshMdspQ+Qh3XJLo4bZbuYvTyFmny7ieppC5ADq/bup7Jo8bcKel5q/Tz M6lbOmwOeYlyGG12kPEQHzcNJbZSE7bW4VXyetdnBp34VuMvyKYTyi9JjrNBSxUPtbrB jUWCzv8l2eUP+PW9PGJ8LTcXnazY/iW3OCIge8JRrTDuHXNsg4ye+38sPS91cLfugYkz jeG7J4VjwTdYLQScvnxf5CAJ8yrMMm+lVQhrvf0LYICAOnE/3V5VVUnXZORohLeRscOL OscQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736243073; x=1736847873; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hm2yrAqNGHJ1ITEnwyw6uBt6Rs3azdjCHMItr3g23Ks=; b=R2GK6Tm1obAnxTibxtvQnzXB5xUYJknPIRW7KR50kxyQSX622cQUzBuNIdXY/64zfS JgqPNKNZBeBvzcLMg0KJv++sqGxbTW/DyrUlpk5+JN5IUnv4knTCQ1pnjeKr35IkoYUb spPQvlWYno4lCNh2gcFZk2nxXHdPR+vJtstJ3ua2sEKPkXuXhsxOLQbF7/JVla349BaC bA8UTexx4IRMWEhLCyksKTRG+KYiWix9iYLECsqREiXUt2PA4zNSEBR5M9fHYgT4Y+ai K/bAmJHieqIbg4+BmzJYZGL+muurx9N3fplKlIMRRkvLR7NaJMMGmKbbWPyG7m0HwtnP UMCQ== X-Forwarded-Encrypted: i=1; AJvYcCXOdmvpVKw0eTosW3G2j9tDI+9evFN3T0yxE2TvfMFrXX2n7KodVoKRHobXoV5K4YpO3N6sMX9NOQ==@kvack.org X-Gm-Message-State: AOJu0YxMXe98shsZG3daJ2FPMwy0vnSJCoRpTBLFBkrKMEgSSVsZJF/Z avNQg70zEWnmldZz+2ij/CpDuq99WTw7N2+sW+39QCC6tqKJUbP457uL2kWjRyBUh6Qorp7f8Eu Wo0SvIRIOD6RPTWRff5G7VKNqDSA= X-Gm-Gg: ASbGnctggUYwRiUZgzOIGuRxuogDVRjvL1ZT/cDqr35HvlP1KEHhyBXrA6cvrO9onl6 DOvizTVhw1plwv/nlFCP9wxyCri8JNi3/5CWMbg== X-Google-Smtp-Source: AGHT+IFVPgj7zgzzI9CW+u4CVWhCfAS/9rruG0BLNUtC3E+JqAHZ/1lVgeQTTXIZ4hWWZB2Y+ps1TkNSUTb59+nQcWk= X-Received: by 2002:a05:6214:406:b0:6d8:99cf:77b9 with SMTP id 6a1803df08f44-6dd23345dcdmr1139180856d6.19.1736243073287; Tue, 07 Jan 2025 01:44:33 -0800 (PST) MIME-Version: 1.0 References: <20241215073415.88961-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Tue, 7 Jan 2025 17:43:57 +0800 X-Gm-Features: AbW1kvaoG4LNW60Jnhm-_tOcb5SX4AEAEkAkMMBOMGXOFpniG7WF7M0OspD6rZg Message-ID: Subject: Re: [RFC PATCH 0/2] memcg: add nomlock to avoid folios beling mlocked in a memcg To: Michal Hocko Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 39544120004 X-Stat-Signature: wg8pxp7zccejokmtu8i14dt1m8kki1f4 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736243074-876351 X-HE-Meta: U2FsdGVkX180iamJPLhsGIbeblfu0RHzT6MIC9vHhEaHA94WWpcXX7jptJwfMWKjJoODcYW3C0ub5ZV7sS3AI/kIvzbSs24wYNh8/M26duq90Jk9ure8TC7wLMoICQX1BKLxVV/8aK3YB32G77TplrtR8l3d1L2izvxrhK8WLcGZ7+hUFp8eLk1WaSTRZOGoX0PfcbAif21FJOjOIBC1d3mFQfHMOLB9wa1mSVJ1RUh8GSHsojND8cO/ZDDROKmUr4ywaBHfUS3CgkhpemDWibLO321PFPjyxylUtCQ9L58eBSUnjqRJTHEY6Rw9CX2mojFi7tR1VM7kBgYt19LKBuHWGpULFUjUnwPNCdXJGvoZNuQGe5UApFXOcXlCT+RALGq+7IW/gQsk2VgJhZhnuV9YtdUaN77ZCniW4kX4UE27Kode46l9vBRmC8+NUJ96K3tAFc+P+8jkwQxO9peLvDzjtSVy1boId4OnELM4xkPk87zx1p01CbhbF8L1yFCt9tiv4ovEEKgQDBp3XsPQeXnUV0l6NxWvLMDunansyZrAk2PIX7QxqKWs0sjKuRAniFOOR1VHPiWgIRq9XR+C0xxIWkWi5mhVucAs4eH3q/h5FjyCrz/o1Xg5bLLgAZFhapCKjL0bn67OIh9z7d1hFKRoz5P4YX5QHTncFs89alg+6/zQr7fXUv7EHZpuzAkcegKTrSGGe+z8/08prNyKYUrHfQQOYEYiEsAPFLxPeJ9Hw7zB16DQuK0D8d1BYzTh58D1BczaHQWcSaEUhf4mNA3pmm/2w1TvZ0CH1Um2FYjMm36X1hqsk9Y+P1vvvk2QP0U1Nw4FnZjHwelLhiuB+GliEvr6BZrz+ds+Kwv2hXAUPIcUdJReD1oYhZifLu4IHxvAb56rX5YTs0wEYiRRvVc3lnIlfRqNYRdavK9w0JFNldpHfD3DOadQwkYgHq2aU4sJVBCq8v4gjcr6NQU te2dNVDT +g1mLhIaHHNRwKRzDDQeL6YMdXhIxVsgwBjE74ny8/iGbdNK31QNZc7bDsPJnFBVCXMdzUrqmeugbkqvzGMKqQKKk8KUdtjU+oy2Y7ngyXS98eK2PiRvzysTkS6sHrGNNc9Lrji3uSi5CW9ZkqebY4b6qjNaStSrADRts50KNdQDCtvCkPVunR+94ggoVui3buOeFrH7p6PnWfEEoSm5qxGZwFKbDZ4Z0Qg4lj7xpTquEnX9zchKtvYntnmt/7hl04El1Xbkip9MZiuZNOAdepLnNm2clzcEHs2X7TlLb7p0IUpQuz+KzK7LLc15ygqHzlYZ5yzGFJ25o9Id1M2KtnrQdHxZhI31c03MxDv4JrwaQWQqrgmizO9fREVVEuCGYtvioiEXVGihk9XFeBswuk1LuN+p/70WiuNE9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 7, 2025 at 4:39=E2=80=AFPM Michal Hocko wrote= : > > On Mon 06-01-25 22:04:31, Yafang Shao wrote: > > On Mon, Jan 6, 2025 at 8:30=E2=80=AFPM Michal Hocko w= rote: > > > > > > On Wed 25-12-24 10:23:53, Yafang Shao wrote: > > > [...] > > > > - Option C: Reparent the mlocked page to a common ancestor > > > > > > > > Consider the following hierarchical: > > > > > > > > A > > > > / \ > > > > B C > > > > > > > > If B is mlocking a page in C, we can reparent that mlocked page to = A, > > > > essentially making A the new parent for the mlocked page. > > > > > > How does this solve the underlying problem? > > > > No OOM will occur in C until the limit of A is reached, and an OOM at > > that point is the expected behavior. > > Right but if A happens to be the root cgroup then you effectivelly > allows mlock to run away a local limit. Typically, in a real production environment, people don't use mlock on large amounts of file cache. It=E2=80=99s unusual for one instance to lock = a significant amount of file cache and share it with another instance. If such use cases do exist, it would be more appropriate to use memory.min rather than relying on mlock(). For most users, allowing mlocked file pages to be unrestricted is acceptable. I don=E2=80=99t think we should worry too much about edge cases= in this regard. However, if it is deemed a concern, we could introduce a "cgroup.memory=3Dmlock_shared" boot parameter to enable this behavior explicitly. -- Regards Yafang