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 7DB24C05027 for ; Mon, 6 Feb 2023 23:35:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBFDF6B0074; Mon, 6 Feb 2023 18:35:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E70A36B0075; Mon, 6 Feb 2023 18:35:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D37E16B0078; Mon, 6 Feb 2023 18:35:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C2C376B0074 for ; Mon, 6 Feb 2023 18:35:35 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A1D391A0B00 for ; Mon, 6 Feb 2023 23:35:35 +0000 (UTC) X-FDA: 80438476230.27.CA74963 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf12.hostedemail.com (Postfix) with ESMTP id E2F3B40009 for ; Mon, 6 Feb 2023 23:35:33 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=gFiziMfc; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675726534; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PebMER0tSx+oPRhl8r2nT8XfQ1hRr+Ea9P0OXUFJBO8=; b=mPrnHz8k7SmRUcDdUjypMYW+qUwgR0Gu38AGBe4xxdqeVwqG5ryTH9uuoN1ryxWpP/cRmN YPSBYj0yrsKH30MH0I7ZFwdvXfwvt+CI6IjdcO7RWu7ZCiXKJQKdJK9PVElJSO8X3eIJ// efowzjOkhWQ88Gxf8mz0fgMbFqajkIQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=gFiziMfc; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675726534; a=rsa-sha256; cv=none; b=kGUXIyeZe9CXWnPI1ZhlSrdMD3CfsPkjFaSsTIfYBz09AVly/DBGFkOdwsTePmd4fg/FLR 4P3mRoqG5drhZCE7vBJGBm/2h2GjJppviNB9ZYwEjxYhUCyYdmEryYdgOdFShSQspJrHy7 vid8+BtiLHvMl1w2t7wwNlFlD2oBQMc= Received: by mail-ej1-f53.google.com with SMTP id ml19so39050878ejb.0 for ; Mon, 06 Feb 2023 15:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PebMER0tSx+oPRhl8r2nT8XfQ1hRr+Ea9P0OXUFJBO8=; b=gFiziMfcVl6htohZH8DlPgIj6VdnPBkJp7qScsRATWcBx+1yfn1eAcW9er4AEysOHd Xk1Adh1uLwfzboDoZyy3rPGdgXK+RZHyUZ32Ow5GPWlnotZgFwNf1tE4/4f/arM8LZvP yRZfnNWC1I694JkleoUgTzrH7QHU0TylPU2krrvGosY2416XSugbuQreh9EzSAQTYxB4 yAJqZnsDw6WYSXo5hhQBYATmHo6hejbhN1bS6ugPVDTMd1by080RDRh/gUqPTjxRmpwi RhJh2zzvqilmf0h2+wraGV49VV+k5Ba5MqNATmTZSGODba5KRZCV1Y7AidKhmrOhn9F8 pmgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=PebMER0tSx+oPRhl8r2nT8XfQ1hRr+Ea9P0OXUFJBO8=; b=z++j2vdnUmsbZR96bC0iS2Ug0i2vnicpsuPp77ylBoObmuaxyufGhqDFEgqNV5TjxD kyiSd2WLNuiLfAiX9u2UbhqiB+RDHgT5xhUheOf+P1bmXYLBEHLsI/0NLyOpPfr44v1M roJIrPmQ6DgcvNCTbV2OHDyo+8wDAcAWvDIr3fuzgymwbudJ9oA0AUWppn1NvpONJDQt DWz1SDYIPBUnpI7KI/JkN/Xiqub46n8EQ2EGS9UuNKrn46FzSguCPM2Ht8P8zf0d3kRF 6yaqPxzsDsCjNanMiHkhtZouezLOajDy2I0+IcwvRpoMfPPsxZbe7FBBAbCGGlRJcYr4 ejHw== X-Gm-Message-State: AO0yUKXhzZxp2bEdR2v0KDH+34QjZmT1Ovd9VEw2H1Y5M42dJNwlqO3U lFsD4+RfWgfDmtaYi4iFIhuzQbous4Q57SjmxH0N2g== X-Google-Smtp-Source: AK7set/LwhzSakQ5P7peQYkQ92BhJVbq00+VQIWbfGe8HACHEPOt/Vfx9S1nCqBe+Ki8mU/16uRn7J/nzy5p/F4cQFg= X-Received: by 2002:a17:906:37c2:b0:878:7bc7:958a with SMTP id o2-20020a17090637c200b008787bc7958amr320380ejc.220.1675726532194; Mon, 06 Feb 2023 15:35:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Ahmed Date: Mon, 6 Feb 2023 15:34:55 -0800 Message-ID: Subject: Re: [PATCH 14/19] mm: Introduce a cgroup for pinned memory To: Tejun Heo , Michal Hocko , Roman Gushchin , Shakeel Butt 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: mpo8w4ithmfdxb9oyt6ryokoamcqoega X-Rspamd-Queue-Id: E2F3B40009 X-HE-Tag: 1675726533-774599 X-HE-Meta: U2FsdGVkX1/3k8jTBu0ZfIZllqP0xYCfUMgmfdfzjpp+mgwV2jRxUiwAoCHQB9saJGnm/jAisG+dw7S9RDXCObUdvPNyVtNzPCWhz/BAdASCt3FKCeSrFo7IHYR6hrOwSbUiMQPi1CjRhL5UChh9h0JljU4BlS/Q0XBtoVhv+YFPsQafbSLTnAeGv8vHypJyRzvCVneMv4RIq/w5rGkISwt205A7AgE/X+2n7Oyx8QgnfI3h/xBn2Xbm45ddOijoQgDRr+VWeJzbB0RLkIree+yI96wvW1PWLbgnkRjMz7OnnLofCDoEOp78FlOncbN6Ss3b97XevDagfLidPJxxAFwtdyMuHjw/bDYK1fDIgBkfcRFwHbxW7Z2KhCQfdlxTzmBJyJJF+/FluBY9BR5FCCXMsZZ5DKVaFmbEMyzRUoClBHid9kiSmlR3mxkuL6ZAps5x8LsGCY7ZU3Y08xMWhHpjxe9ymSYJw8ts+4ECxYSyd3uYNoV1CmabPvsM1bcJ0NNDa5O+aNbe35gHC/VUtNI5h+zX6l749G1hEg1vQ8COW10SAbt5KkCxw7U/qpfHDCONgFC4/LpBYbS3rE3bOhU+z0XarjaS04fwjCuFl5+cZH8vzd1W3zE0dVasmitlkR/sxfiWVL1yhpL15xX0UO8aY33sn7l3e8bnpHYPW64CwpY+hPChOG1WeaHbRFyP30l/2RgMq94c6iXi7JzUFEcn6QEtOcz/Fh2oZkgAQsZOwdH1RoadaKQPCeLiiSgrVMe6N6rhujp1wM/CyOAbbWrV3u4qfHcvK1BTXEQMXSYEl+YD0UU27MYtY3pRHpafKHCRDeSxRRXRdIrp3Qw7HmqPssrCVVhgbvBtwgpwX/CY8npbTBhtWGGRPvmh3LapjlXt4SdvXbkHp1xo9BQofgKUpCJNngdRCdMyTHVQc++IZFn0WlYAgeXtazZZhFG/NTjNQsMKnNN0BYcAQw8 sYuWQ7bV ltZrpgKoWEAbXlmVyyBY7G0XVdGOWechGTsTlpnN/vmavxb4LQRFm7RH6Vpg4Tfb9wgcpH9ch8b6e/6nwjyuQNQBwXn5l2gRWOc0gPRR9RGMQE6EAWZcNbe71SFBlNYZ+AM/S5cdJ0S3KI9zQQw9EeO2rKmLQPlsio9hbb8y1crgC6KdGPtgpLVfJ1T+qiNG7B0eNLoBr44vEUmTyVmjY5SSA45lpoqJE0N63iC9EPxRCn1h6n6JcurNEjqpJehMNWnUtO79Km+KG59ndFfuqknOmiselWZjhhJDeUMRYtx6HTCw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 6, 2023 at 3:25 PM Tejun Heo wrote: > > 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. +Michal Hocko +Roman Gushchin +Shakeel Butt for visibility with memcg. > > Thanks. > > -- > tejun