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 DE375E77188 for ; Fri, 20 Dec 2024 11:52:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54C466B007B; Fri, 20 Dec 2024 06:52:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FC966B0083; Fri, 20 Dec 2024 06:52:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C55F6B0085; Fri, 20 Dec 2024 06:52:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1E8666B007B for ; Fri, 20 Dec 2024 06:52:56 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8EFC78093A for ; Fri, 20 Dec 2024 11:52:55 +0000 (UTC) X-FDA: 82915174524.27.087C767 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) by imf10.hostedemail.com (Postfix) with ESMTP id D4A8EC0008 for ; Fri, 20 Dec 2024 11:52:38 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aYdHnwN9; spf=pass (imf10.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.41 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=1734695550; 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=iOfFO69Wr5jdahBQ09iVrsPC0AsDU3AqIBIJ8rwQKlU=; b=VM3DNMTbe0UsHiQb5yR1emXDoSIDt8n8n2+kFoPYTeBGfW9coR0vt9WSxmt+zZgUPv3FJz oOhjDLRbFm58z5yHdbS0nt7e0doQAMDOxpsE/iDdIyCh+xgbrvxNLkfOORnoX5tjzBpo53 hXxb56no/IlJsX1ByjH5HC3MJz0rMfM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aYdHnwN9; spf=pass (imf10.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.41 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=1734695550; a=rsa-sha256; cv=none; b=UfCidIMxgcb9Ulr0cJYbWwFRJWfmwDA9xnLiZYdkOr5zzhVd5Dkd1tVLUlcdDIERniwh22 uZQ7iRoRmglrX8O0UckeUCx4B6i1gigNQnL04EE0BLqpdTdz6PI36XpZUGHGllz4tSpRiH RKW7+O9pp7tjQOdxv2183r/HksA6wbg= Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-6d8edad9932so12843696d6.0 for ; Fri, 20 Dec 2024 03:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734695573; x=1735300373; 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=iOfFO69Wr5jdahBQ09iVrsPC0AsDU3AqIBIJ8rwQKlU=; b=aYdHnwN9WKeb72gsb0/yKEuIOadOIoVbIAZwzDR2se1tpcqFuW7e2XqZZqYUKjMsyJ rSrmUcyE+y46Jcv0va7SawwtzRU/lsbql1C22bZrpuiDtAtSoyaWVBNGQ8fSK4OEIE2b e0/nLPcFw7pX8XKy5uZOOw+N/yIsBbq2M6+R+acEhInTA+yaAHMt80uVzo7HGCPJA05Y 0F5Nfc3/v/85+f/OUgdAMZQKw6sGsHsNlYbXgrkbLDYQJWLulvMRSKL1/WQkAbC0OeT7 5/Dsk/L9rgwSziX25SOLVjXpZlyAP/6gIU6PMpxxb1/xOlLnhVVJbvL9F6H4/FhqOV2j fFwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734695573; x=1735300373; 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=iOfFO69Wr5jdahBQ09iVrsPC0AsDU3AqIBIJ8rwQKlU=; b=ByCqdVEza9LemP8nQLnK7Tv97N0NLQ/PUyRfVtCuOQ/NmQnOTbk64y/wIbgBhIZjRc 4WQKgrAo7Q7BdBTGsrNxQ0rFWFBbNZM77bUDqS9nnszA5VWgTGlv7i+9cPwNhqEpp8rU 58XI6xV4xWxT46VWdSYWdJFCtD9+LQLwEAxE2Y5XNP+miKArRmgMswExdgdNLV0OgvRO mq+y8tGkH8TwKxlqeh5KJc6nUND4ZeaHLf5uYXyIQ6wzclPPiaAgFVu9Uhb4pmCL/ZSo 5xNKM+6j2KuB1/TAFjB9TgA7BbTim9e+eAMpSt4nARyh4ok4N29PIX7wW0SUZ3j3j/4f VO0w== X-Forwarded-Encrypted: i=1; AJvYcCWNaiTkmjFXxNNKOHvgtuA9I9gCGx1Hi/A+1zlg/WCIMf9RGpqO4rx4VURQYXm4uMPQSy5euBHutQ==@kvack.org X-Gm-Message-State: AOJu0YxlQrv55q1zoo9dnwMHoEnTUCm+gjcqM/97rPGKYx1UQccGYrDW MmYfMjVzEpAst2vy78K1yX+wqinSG6nt3v0rcQ/WCQWCziK1wkYBvwSZ6/vQujjYUaDxKQqO+2S j5xtLeL4J7ugRTsNqL+ubAaDgVmA= X-Gm-Gg: ASbGncsfke1ASNvSyBVb/YxPSKFYdXTYD+uBSpGtR7Ol5cpKQPuN4CafBxl2CGIZnAf gf3fYpoAIwIsQVS46F4gaymXLukVxtrAcRroZ1w== X-Google-Smtp-Source: AGHT+IH5efAZSKZ0jRQ24i3pcICP9sDfRWXHCj57BDd3BYfD6AjfDK0zf7I5i+EEaCGSToA6eH++mjR7S0baCrcRubA= X-Received: by 2002:a05:6214:3a02:b0:6d8:871d:6fcb with SMTP id 6a1803df08f44-6dd2331f221mr40764666d6.8.1734695572826; Fri, 20 Dec 2024 03:52:52 -0800 (PST) MIME-Version: 1.0 References: <20241215073415.88961-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Fri, 20 Dec 2024 19:52:16 +0800 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-Server: rspam05 X-Stat-Signature: qrrdkjh9io7z3dofhqmriw8yax6t8ogw X-Rspamd-Queue-Id: D4A8EC0008 X-Rspam-User: X-HE-Tag: 1734695558-890976 X-HE-Meta: U2FsdGVkX18hbS0+o3xIjccL32NwDXK21zOj/xSPJSkHvILPUBsJkHL/EIkL23BFLPcOV5xShycBf4fgNIK/co1nSGehhuuDuXlF37ANFDn6qBdN5jDv7hdmq845RCvEbkeqqKGqW6bN6wG1+HgyDRyZBttyq7hl5r+uZlHE3djw33onT9eO30JqjKASVpLqpe0zIHvSlEolkU5JFBn0sAd2Og0hqMVf0vcd05rKbiXf2Pe0xTFHvzeKW8Wlj5OFfHFdkU7PgNYTYwyUC9W+pXL6xd0/hIRJco1amoLNgehOmqzBrYCPGhDZAsPUG6Czgk8iBnCUUZoZvrMIdPgF+2CkPb2kQJVxMvXGUE6C8n5CFg0s9f2IPVN59aI5VFxRB8g2D24LSGDzcaf4VfxVmo09Uy2iWPCadQ38XuSBBWQKeDRJmyFSYijrSq3oNvp9A4pSv9t1cK+RuKNZxFOqOXav4iEG1W8MXKAgSg33joDP50xi2l08Oe8q9cMPs9mDPNlYSPmEZ1bkCUFazMZxNJRiT3DQvyX3xVFd5ZTPzWJ6AD9iVu9MFJfZKsgedpqGDONWUrubGhlDukAKvnsoZ4EhfSYwsqyYU/2iFFbRee+X3+8FmW7FqTT9Gvd+TpBkXlT/GmuZfXm7O5NaCp2ELEQbnFCLWmoetyGlMo7235PQxoVFNg4Ah5sMOAgMYgMrXTMHadU3SzLpGJEbzI71RcSu+oDwa8xqvLuHfMMllQL5q1fUObyE0CqcxMQ7D16Y9q5bC/Hifvlj+toYLGFtoFKqGh7Z/XeqFmQedRO6/Y7dmrTWPjXBhkN31UIEeYUphSJ9Ihw4VofoC1Inu1/9ohH06Y2YO4u21bCGcABU9kLiv22mFzpfBIyilqXFi+sSr6Kmp+y03Hg9KU5KLVqK0QYJZKcAdYnTgQceBKWyWjT558JZSrBkvX5OyCxEmJCg/fBoXD3o4KcN7G52c9g mKvdERSd bTmjokmMMKUd8r4efx0EHBdz9OdWtRY7aTFM5a7jK0s/IG6uDsbHiCMPJbVo7gyI8DNrv/4VUjt+akmhwLe2+ddj7YcaTnBzXOPoGoDk75l/E7mL5lXkQ+Mrl3Dqy34+Wfo5p1ue5dAToTVMHLtm/CWGuzPan9VBdfDf8ovuuMVImSLMhvlVgIyNYT13qihaVymN9HjJc83D56LCFQYEgjzWu2CEWIffiVSeG+x1YYqqoaexYTgbXm9VUDF0ATNeMwbWM2RevSyJpTZG94C4N97QX6EzUjVHqZmVyDRVHO8NglFINbSLBYU6Wm4dSmAZtH/WoBPrum6Ffw+39uJp8YwtDdM67J8LxipInwx52sMCTKKpvf/+JRLFtFeWmsJVg0hynblCTsYMSIFA2kuak0GXulOKcnC/uUYfx X-Bogosity: Unsure, tests=bogofilter, spamicity=0.479844, 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 Fri, Dec 20, 2024 at 6:23=E2=80=AFPM Michal Hocko wrot= e: > > On Sun 15-12-24 15:34:13, Yafang Shao wrote: > > Implementation Options > > ---------------------- > > > > - Solution A: Allow file caches on the unevictable list to become > > reclaimable. > > This approach would require significant refactoring of the page recla= im > > logic. > > > > - Solution B: Prevent file caches from being moved to the unevictable l= ist > > during mlock and ignore the VM_LOCKED flag during page reclaim. > > This is a more straightforward solution and is the one we have chosen= . > > If the file caches are reclaimed from the download-proxy's memcg and > > subsequently accessed by tasks in the application=E2=80=99s memcg, a = filemap > > fault will occur. A new file cache will be faulted in, charged to the > > application=E2=80=99s memcg, and locked there. > > Both options are silently breaking userspace because a non failing mlock > doesn't give guarantees it is supposed to AFAICS. It does not bypass the mlock mechanism; rather, it defers the actual locking operation to the page fault path. Could you clarify what you mean by "a non-failing mlock"? From what I can see, mlock can indeed fail if there isn=E2=80=99t sufficient memory available. With this change, = we are simply shifting the potential failure point to the page fault path instead. --=20 Regards Yafang