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 18A11E77197 for ; Tue, 7 Jan 2025 10:04:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EFBB6B0095; Tue, 7 Jan 2025 05:04:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A0446B0098; Tue, 7 Jan 2025 05:04:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 740D16B00A6; Tue, 7 Jan 2025 05:04:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4C5986B0095 for ; Tue, 7 Jan 2025 05:04:55 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 931541C75A7 for ; Tue, 7 Jan 2025 10:04:54 +0000 (UTC) X-FDA: 82980222108.27.90CD4C1 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf03.hostedemail.com (Postfix) with ESMTP id 6EF0720009 for ; Tue, 7 Jan 2025 10:04:52 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=U6Kau7Z1; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736244292; 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=U3kwXwpW1+9FRgmpU7rvTLLkST5eIiO9pkO81j76ueM=; b=xQn8WvM2l6weJbCJDco+blDlEwQ49wzBg5m/fBLw+ySN18oSFgjfsU/WC1NFvveulRWsfs vvdjmy9+KGf4aHQKEVpxSrf+LWukDPz5Ys+5sKIGvVx6XpsUJBUUFRUKzBB9a0l4mkao5N WEhQspfYTEpSt2C80j4V6aSErjNq8T0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736244292; a=rsa-sha256; cv=none; b=flKzvRlruh7QrnbDPJF4K6DEpPetLfr47xKhKqHWCrOuycPCKCf6bJ7yuG6UqNniKLuNX0 chjrrt6erZVURevB/+r/8jRCxqluYbquFPMM+JOVolmxAfncOLs95QpBie1Ih3QT9QMUiz AoJM2BRRQuBAONoeYOUNrfU3mYB5utU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=U6Kau7Z1; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-5d34030ebb2so10666282a12.1 for ; Tue, 07 Jan 2025 02:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1736244291; x=1736849091; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=U3kwXwpW1+9FRgmpU7rvTLLkST5eIiO9pkO81j76ueM=; b=U6Kau7Z1sEQ98GYzMu2g/lj4atjjiIQ8fAhm/NAvuwACCi3hzo7kvVBVfT0JKTn3m0 pLly6m60pDcu4DTWJFmqEiG7W0o6WwskAblFfRn06Rb6/tRGLozyIeFpONv6pLGYSk22 4jngLTGk2IBrSopsgwoQozlAVYgYlXSyuyU44397m5EplM2+sTGBMi4BBuwYrlYde2xk 4ybL336NNnKPg9x7RbmUt4d74457LH+e/pZxqBNI0WHHEkWcN6V/RuUVuTk75d3wG4Hf MV4cYysu9Cpe96FkIEzQcEVjK9yJJBKb10N+5CsRxsQ12xv93Tle78iLn/IiRm0XIpRF nhTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736244291; x=1736849091; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=U3kwXwpW1+9FRgmpU7rvTLLkST5eIiO9pkO81j76ueM=; b=ks33kUwSPnCS+QP0/UlOaMHZ5EAId5KeK4pQbZVngNpwe9exxEdTlm82F4htLFXjLm JGw3WVcQkQ5JKHzbV7C8ubR3tDXu4o2SCFO6FAr4MYeLP80FqAAK5/MCYCyOKlMhRYZz 2gJFiVbpf/teijrYo9ts5D3ecoAynIFfej1n6xiUmxNVYLyZH51KLzLAZO6h3QBUSCbs MYAeJAlOjNDuqfZG8Qcj/EiEoIOiEmQPDuYZjH3ea4xiktVaoeuxkyj3xNLL2ESVDYU7 JxWQLr3kB4H/KLTUTgA07eQfBDUwrauWYDdjo4dBhbsf9RSCxyPVU9LrM2GBz4IPOALJ 4akA== X-Forwarded-Encrypted: i=1; AJvYcCV88IGZJEW+9Hgr4sHBtx4t+F6wsqkLn+hvKtyY3WN1bI5Uu8BSL3PJDNr1EJOn2niVLcDzhC3UKw==@kvack.org X-Gm-Message-State: AOJu0YyOCk48Yw4YT4aWdWCxS4zesCDGnYoJC/wHWZCYPy3Wla4KPHNX fpEtpRqRvpjg3TW0WIyXi5RulEJfgzeoU/gvgzjv+kbyWh0qdMQxwJDLR//gDP4= X-Gm-Gg: ASbGncsAP5gkKanQUOKRmhTiGLfRdy3Cl/i5H2uWa32fEEw5wr/OckeKtpDew0I6l9f 90LS0yXMHZ8RQBC9kRh69FYXW5RkiA/80AxVCi3hpm7AKQMD6qa0YCuHS+bTGlGGX2GnDFt6eNP rbLcD/Et/Nx8aG/2qpaJCdFe292rRNYOtFgLYPYv96g8/pM6p0lyuYhPnGcrYMN6EDNBzUIxZ17 xiSICy9bj46S2aVJ9ejZCSNJWOT8SmNhrTwVjEfB2BNH+WLgYHBopUZg73CcmyCAQLHiQ== X-Google-Smtp-Source: AGHT+IE63NvVyZNKq1phWUAcUiLcF0zhsPAI9E9yu55D22USHeexIO1Otm1pMRRXiWs0CP7drVBpAA== X-Received: by 2002:a05:6402:270d:b0:5d1:2652:42ba with SMTP id 4fb4d7f45d1cf-5d81dd9a22amr58696781a12.16.1736244290702; Tue, 07 Jan 2025 02:04:50 -0800 (PST) Received: from localhost (109-81-95-200.rct.o2.cz. [109.81.95.200]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80701b148sm23951569a12.73.2025.01.07.02.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 02:04:50 -0800 (PST) Date: Tue, 7 Jan 2025 11:04:49 +0100 From: Michal Hocko To: Yafang Shao Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/2] memcg: add nomlock to avoid folios beling mlocked in a memcg Message-ID: References: <20241215073415.88961-1-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: gxsw44urfc3bhz4bcf1krpqnaafgcrbh X-Rspamd-Queue-Id: 6EF0720009 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736244292-68687 X-HE-Meta: U2FsdGVkX1/jtV7a8S8MO0FRgjEwIjvxGd97mtGns8PrY3Rr3r1u45An2Ah82mLOw79pm0OTOEPbL/oETjpCZgJNegv+Si0ATa8XX7Ug+2EVWz/TUke6Tn7tgp7P8+2RvzwALmhoHFiTyuNUBl8hWTaFWRVm8pey0ftrTVdDzUrk3eqeCxqGF0EfdtWdSgVRRO7WwU9KOGbwTXQR/yO3IEXFPbOa5ZylpJCQjYip2NFY3nWoXDA7uLRkN2oNJphgj6YWmj5E1gi0DynKMnrPj2DwcF9pbpvnF4SWDwI592tpNQnUFV/rRgI/lxhsAQkJ+Hi0wxMudqXJdbejre3VDl1HHOzbh83l7/AV0ALwmdewsOfT0oTGcYezJn9zhpz1xVHOIWiq92fT5FuAuAQ9hUvw3cfNG91SjgUH7lqYWfz+4OlBpKKH0Eztzu58TznBizuJGHAejuplWSKjBy6BLnlRE3cMeeCSswrDkxX1lJOLRVCSkfx1l3X8okcjLcL4eqpLyCtSokoGH26KL1IPzMLL5GcCFDKLrSk/RIsDAq3nrJNbGZghfVTdNSMeG/Rp3fPd0N6uLKLSY2+SyU0euJXT3Fg5ymtTHTUk6eC4+ThpqJfFO0VzMldXvQRTzJpjMvCjQbUm315JYZV4tItJrzwZSAden1k2Vz/KS6/A3+DrTpAQ9LpsicfIzueGqpttcrSZAkQUHTyjEKo4tyDTR198Rr1gAT+w94KC6D8bhv8l71gUh2oN2i8RtnQ4LXW0WQgN0ByqNQU/OpYVHuvLYw3MjAe01BMJuGSZLO0Gr3vOGEF+kJ0nQs9nRlQUr5daMwR/5sed5wp2iRvGKTYeknJSsfijPVFu2TTfgonHsV/ZtCXuBnlaIyBa//xu4jPlcvgV0B/aECHM8S0rpK5JE+K/+nAGE5PVetczY6vQzvcb2mY3bNF2rsEOlxOMOdcfNztGnfuZCLxONFSloLD Lsg5EI5G PKvDnv3gOfYYhYvhJpdCHz799s6917YDlrbwgXmeSYOmdNzqySQtKMJWgaAF0yQWt8fihRoC2AN8DZHXp1JQuLUzkI2SiP/M1tssbDy6Zn+u3hSGLHf5gZzjjsItDOy1Au/KJl5VOYi0+FoaU05ogjGFdy+l/xSr9J0KKGLTQUv5ri0V9fhr/RYVMJXrVdXTnl3F8gLiOR5uQbq+/rAFB8pYw7TfQVqI8pcb8Y62xUZAp+q3fWedZVXQ69HTfpJXNGw5TwraKQ009nHxIo2iH7TyOymV4UNgj6qPmUsdCKAl2odOSlmDP+XHlF8QwVVY7zp9HdndyEY0E5T6dWO7JZUAwkuNXFAmRHs3H+uPEZgrJXApFLob8zO+6Qx47m0gHjORT2N9l+zX42qJ/YuKDhiSa3OdJjhieufQzrLmidG5nNJ6pNkU5zYcUlIJSUjOvUVuqIITs6No9gazDXEe/hK2y2kHhjM224dbUGtt/rb6MqSwDVARIVp2W0VgxOyBz10Rtynz+IVejN1ZAmVHcehKEKpyVXAMiB5f9f53ttZ4xBuY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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 Mon 06-01-25 21:59:07, Yafang Shao wrote: > On Mon, Jan 6, 2025 at 8:28 PM Michal Hocko wrote: [...] > > The purpose of mlock syscall is to _guarantee_ memory to be resident > > (never swapped out). There might be additional constrains to prevent > > from mlock succeeding - e.g. rlimit or if memcg aims to control amount > > of the mlocked memory but those failures need to be explicitly > > communicated via syscall failure. > > Returning an error code like EBUSY to userspace is straightforward > when attempting to mlock a page that is charged to a different memcg. EAGAIN is already documented error failure when some pages cannot be mlocked, but yes this would be acceptable solution. The question is how to handle mlockall(MCL_FUTURE) resp. mlock(MLOCK_ONFAULT). I didn't give those much time but I can see some comlications there. Either we fail those on shared resources which could lead to pre-mature failures or we need to somehow record lock ownership and enforce it during the fault (charge). -- Michal Hocko SUSE Labs