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 5338DC05027 for ; Mon, 6 Feb 2023 23:25:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B92236B0071; Mon, 6 Feb 2023 18:25:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B41CC6B0073; Mon, 6 Feb 2023 18:25:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EB956B0074; Mon, 6 Feb 2023 18:25:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8C5206B0071 for ; Mon, 6 Feb 2023 18:25:39 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6809F120A35 for ; Mon, 6 Feb 2023 23:25:39 +0000 (UTC) X-FDA: 80438451198.22.59F2D5F Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf24.hostedemail.com (Postfix) with ESMTP id 87D7F180012 for ; Mon, 6 Feb 2023 23:25:37 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FM7dnXdD; spf=pass (imf24.hostedemail.com: domain of htejun@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=htejun@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675725937; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HNyTUpgbSKzrwdLKzf32iJthR0x3bB6/K+FM9veAVxs=; b=G8ibFLZWzs6lwJx7GUJJmL4y5CuXkzCrqDcv4fSHfFogyTeouPSvMOYnbV2/qJgHKZQ8t7 wOmlBV3mYjCWVjlm3BIfHjV3LrACRJoPyNllIU4mNPf+qAiQsDnv2fOHT3XvqUwcAmXhk5 SjaOkjftjCEBizPYWi9fTZIjfndVBpI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FM7dnXdD; spf=pass (imf24.hostedemail.com: domain of htejun@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=htejun@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675725937; a=rsa-sha256; cv=none; b=csogfQqBryhMTBRwCxGp9SbGicVPhH87/qlLcIaA2NraN59jo+f6d6cr7L5hegzgGLEKSc gmVei/41z4TR1TG5fW7cJtFh5ib52QSH4ipqDha9IjZ3vD0PR8PHE3LT9xgwlwPfMid/Yz fZWrj+fx5OycVAp355rCzhzDfiC4aA8= Received: by mail-pg1-f172.google.com with SMTP id a23so9292018pga.13 for ; Mon, 06 Feb 2023 15:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=HNyTUpgbSKzrwdLKzf32iJthR0x3bB6/K+FM9veAVxs=; b=FM7dnXdDgTi6Jr47ShxElcXjWHf8/UeXvO3sG8rOKcpJeNHNS3yZ2XMQ09gojvSZUS jMC4v/s3fIbXEZcN/hWXAinwIoADwF54gqpJzyAmLG/jbFAHMl9869uZNSn/EQ/c3cU/ sSbheM93Ql1q1GVQvGm5T8KF3HjrEq/J8nYdjQhM5vzRpmxJChWw6ik0kM0HJ9yPYm5c kyLv7nW5pIeY74Pf81p5FQy9U5vEoHktgkH91nRhqZSmdrkaH8/x6bPrRvCzwgjpIw1M Wri0s5FTjjOgIiWOKdnX3XaJkImD65FY8TNru+AdsHrWWqYjwDJTotnvtTfaZDP4NWUu 2NlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HNyTUpgbSKzrwdLKzf32iJthR0x3bB6/K+FM9veAVxs=; b=5udqNKvYkcJee4TUesa2/ddKzhid2z5BXQ6dIjQOZZjEvaBw/90pnRQWUKJIJWwhI0 By/fknBrZct3MnRT84T8z6TaiEfIGmiXj7m7e/ejvuLwmZ7LP9K/uGMfWYuSEYgqgX2O BqqS3Z4jguj08blMjECsaU1zCdVb3p1ZdPuF1mHvcKh/hsVNq32xIEORnFBs9nkWo10T Z9YA/g6whkninetFNzDkikO7+pHQlRoeNXDkmYGAZv6alYNu3qvDe7C4BRlHO+xLjM7s 72PEQ45TndG/6LJeE3gq8FKGQ7HDfPxydxilabR72ChOsxoav68a8pWpODWrcgVvmTHB RhUw== X-Gm-Message-State: AO0yUKUfAsNYRhEzn+89Dl3TqgNOB/aQg2XjawaJczFoFAV9cvna6naC Lq7vy0nmdwT11j8Z31NRQwQ= X-Google-Smtp-Source: AK7set+OLNZIETla8KPC9TCHUzFLdHiTMYTyvd0ctdu9+qHe6fVJvB2/KVw0/D/ECLFVYvUjoRV7kw== X-Received: by 2002:a62:1c88:0:b0:593:893f:81d7 with SMTP id c130-20020a621c88000000b00593893f81d7mr800938pfc.16.1675725936087; Mon, 06 Feb 2023 15:25:36 -0800 (PST) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id b205-20020a621bd6000000b0058bc37f3d1csm7694842pfb.44.2023.02.06.15.25.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Feb 2023 15:25:35 -0800 (PST) Date: Mon, 6 Feb 2023 13:25:33 -1000 From: Tejun Heo To: Yosry Ahmed Cc: Alistair Popple , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, jgg@nvidia.com, jhubbard@nvidia.com, tjmercier@google.com, hannes@cmpxchg.org, surenb@google.com, mkoutny@suse.com, daniel@ffwll.ch, "Daniel P . Berrange" , Alex Williamson , Zefan Li , Andrew Morton Subject: Re: [PATCH 14/19] mm: Introduce a cgroup for pinned memory Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 87D7F180012 X-Stat-Signature: 5q7wnxo8ks9r93hnondpypnyq7bmj9b4 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675725937-41497 X-HE-Meta: U2FsdGVkX1+iPICa582/LKFaVRQvBIM4u+5wPjdMz/3Y9xcIBy8QwhBHhzlIH/anrfKZXKNeU43CuISPR/cOf/572sgZoePFLgy6SCAxdqGhz4cL2GoLoEQLz8kHWD72B03Ams0Y23jG9cjwgJ9pVdqrYcVu82Y+9QZ0UV5knzrH47kvHD4rxnIg6194soBlnpDQQA0T4DoInQ/FJbwOnMbu9nVR85yvkFpzooPpkx3fdEJMk1s9NO5z42uh6gKd7eQB6b0g3+D9dOOM6zugGg1fIY8eJ62FcWhDC7RIrAib7F/OlvPBJRpDy+yGIIMgEtyZNqNDDpvOU6h7CkwhLAL37tw7dbx42P7Z1VpUB/MJfQ32iXkEVzc/xgCx9c7VOGDtrH5ZoeL3WCcKC2S8b2Y+RTBIHRrHdRG0pmznE9KF8C6AAXTVL5ZrzcndV4GxR9VLLiNOvcdAhaBMA92o2fn5dzfiptTACt/FPZXd/xQHUh9fDFYaLU36BPMMHky+TQiCUG7rX4PX1UL//MySbcjJ8ncM+xAIU9sD5SYGmlppyc/tH/eUNKuelQTxz2PNIs6ORyAuvU03EAm10EGZe3o+nZnD0zyyJSLcxEtetP74g4Gfr54kdBpU35aBYD8KuH0m/Kiqty9tlWhDEJ90WHXnFta2W3odfq2RfnNIDb+VeFWkfSACHh0O7bluuGZCAsWtnEgYz7J1UdPFcrSH+A4/l3gPcCoQAYV/ErrD6+1QwjlVJObwZkYO6LIW2TRPka8N5XmafjSY0rQl14BPdC/a28eBW4v5/Yld5WKUkb5tLWM1tKUcA3CHye+gxcNzV+lfSsKsdrRZjPXgMt3B7KuswUNSRMnv2BH1Z1uqzXEWe4HliULakGqgevFnCIBfbysPbNtaGdYRkHuWMNTTfe59IC54Q2cgsX/4cHASO2nVplTGmWPiZganR5+SMz6zmbSsDP02WxSngqQBmK3 mBeTiH+/ KOMHv2PGzItzQWSJw3j5ToKjg9DXjrcbOAAQKcoVPSkgziK2XSBEgK346NxHV1L8frIlQQTvHEy9WqoPDp/6Zrq0iqinRHzWuTlVb83y7hZYinip89Ju0Qm+t8iDJeYG2Tlcjd5fnUe1q906fbDSCrnWWV2hnyUW5cqnQ4D1CJWMdQUbWtf8HNFu0OBQZDKOWshqIOFYsriVNOmx5Urnh3sCnU0COONeY0aMLcVgQ6KaLdCcHM85h669A9D2mxpu0a8PL4Hc4n8pK8bkmnNhH2qgYIUOOl0w5FSdR1YFw4b+/9QRe7BexQgsgSHwKeWmlVWh2AjHa4pEmhnDK2tMJwsA81u2BP0fA0vJNZnfjnVd/9wE40IQMhjYy7YfgeeOOJLiXgGWhmJue1oSbOOAPwZY75e6yk52DlV8p8OZeeIj8Qo4/E7vnC0x1U2JI3vd+7ij7rIr6zp9HLd4rDpjcFtEdLg9KD2FTD8cJLCPqTU9X1Ny/K9mG5Fm6QUYqTlegrYzBe8nx/hVHvbZAtkNoen3SnFMVKw7upKWMxWooCZf9BF6gDo2Qp4oR6g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 06, 2023 at 02:39:17PM -0800, Yosry Ahmed wrote: > On Mon, Feb 6, 2023 at 2:36 PM Tejun Heo wrote: > > > > On Mon, Feb 06, 2023 at 02:32:10PM -0800, Yosry Ahmed wrote: > > > I guess it boils down to which we want: > > > (a) Limit the amount of memory processes in a cgroup can be pinned/locked. > > > (b) Limit the amount of memory charged to a cgroup that can be pinned/locked. > > > > > > The proposal is doing (a), I suppose if this was part of memcg it > > > would be (b), right? > > > > > > I am not saying it should be one or the other, I am just making sure > > > my understanding is clear. > > > > I don't quite understand what the distinction would mean in practice. It's > > just odd to put locked memory in a separate controller from interface POV. > > Assume we have 2 cgroups, A and B. A process in cgroup A creates a > tmpfs file and writes to it, so the memory is now charged to cgroup A. > Now imagine a process in cgroup B tries to lock this memory. > - With (a) the amount of locked memory will count toward's cgroup A's > limit, because cgroup A is charged for the memory. > - With (b) the amount of locked memory will count toward's cgroup B's > limit, because a process in cgroup B is locking the memory. > > I agree that it is confusing from an interface POV. Oh yeah, that's confusing. I'd go with (a) for consistency with the rest of memcg - locked memory should fit inside e.g. memory.max. The problem with shared memory accounting exists for non-locked memory as well and prolly best to handle the same way rather than handling differently. Thanks. -- tejun