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 B2BB4C61DA3 for ; Tue, 21 Feb 2023 16:51:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D7556B0073; Tue, 21 Feb 2023 11:51:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2878A6B0074; Tue, 21 Feb 2023 11:51:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14F526B0078; Tue, 21 Feb 2023 11:51:54 -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 049146B0073 for ; Tue, 21 Feb 2023 11:51:54 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C0330AAAFD for ; Tue, 21 Feb 2023 16:51:53 +0000 (UTC) X-FDA: 80491890906.19.479ADE9 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf10.hostedemail.com (Postfix) with ESMTP id DB5B1C0004 for ; Tue, 21 Feb 2023 16:51:51 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QJFpoZEx; spf=pass (imf10.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.49 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=1676998311; 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=paiWRoNE8g4hLYXHv2XDWIFqYN/iFdKjh/xR/nU7dP0=; b=tEVCT4xckvBAnj57pZFkRmLNx7D62P5RCtOwre6WeJTBkRKF3/Le+10cCBwFOryjRLLDI9 ZXDd17HOirHEQaWwgzJg5OHG9x3tr9Q/XyGfnMng6BTCtmtNg4u8Zgp9k3bqvf8WjAHIs7 YWhSA0xzf26LaPyY5VR6qyHyCigOnAk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QJFpoZEx; spf=pass (imf10.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.49 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=1676998311; a=rsa-sha256; cv=none; b=oWtnykMNn8nSbuaMwH0BdI8RdOxZHEsCxmfhfv7/RakNEAqR+y4t1iyWStUct0q+6FJHjY IGBAqtGTl6JIvO580+byJQg700zqTJLSAF3DQexDpDOA0VD+QWrpO3x/FXe1PLf6thnZjB M5KOJ5tcJmTI1gfBD7lyeG4cs1B0+ow= Received: by mail-pj1-f49.google.com with SMTP id qi12-20020a17090b274c00b002341621377cso5447678pjb.2 for ; Tue, 21 Feb 2023 08:51:51 -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=paiWRoNE8g4hLYXHv2XDWIFqYN/iFdKjh/xR/nU7dP0=; b=QJFpoZExKw/R6r2PUd+5zNoa5+G7LbcTOlmyv9bYwCRc5oRXqPs0cXfyZrDZQvOx5r NJwt1nZDhqLQfxwo2fy2XfsfqJSQj6w2qwIqL9JLosB3hr5ZTjA00J3/L4I8NI3vUVxt V09PAMnguaISmOA7ewfvBPUYM8fkT7FPC5ugQakxDemwbkvtugIo9X6re+G8cbC7ifSa zL15HNoHTariSPDw/igK8OFTfJvpTkPGAD6iLlY07tZ96GfsOO3H6JEURvDtL26TDdJV /WbjWfu1QRSWfVBytw5xsskhhfDzZE5KaqhgaGo+JJT2i3CilKr+EujAv5TgMBjZVmPD Ge7w== 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=paiWRoNE8g4hLYXHv2XDWIFqYN/iFdKjh/xR/nU7dP0=; b=w3CJqk1spvJpiXZQV04wOFzOA6WJkNpwQeGe0jq2Q+GnELIx0mQk8t+EGZJTM1ZZar 1Jam7HfaaCZ1DChR3u5TfV/YNE5joQScA6qMnb532s3Gc1DOnagSGneb9ZUn4NELw1bS o4KO8fIytl7nAQPtqad0EMJP7zhphTTYHLwwraYgi5C+UitPAUp2+lHUHCKCwcSVMjxH XlzOAzG7Ppr4+KzvTKmUGdL8fzvJPGaMbLTzao642H3RugSWlKcyDZUG7+ueokwK1j3T l/yvQu7bTE3PeUKEMsoBm6AF4TL0wsFl8R72JrajzYWaMhbsd9gPxbcuAaXWLOqxH5lQ IHIg== X-Gm-Message-State: AO0yUKX/lW58N967yZzh3iw2BsSwas5UsPebGhd44xGZitXGvkGJpmWc nbJWsl9Ip0M/PqqJl+TNxpQ= X-Google-Smtp-Source: AK7set+akPqx+gmedMgaV+asR6oy5RlxU3pMn1PnO5Np+abmd/nQHxRZKSg4rDU7nLktvl8mibviKg== X-Received: by 2002:a05:6a20:8f26:b0:c6:7673:f392 with SMTP id b38-20020a056a208f2600b000c67673f392mr6052804pzk.17.1676998310343; Tue, 21 Feb 2023 08:51:50 -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 m3-20020a637d43000000b004d3f518eea7sm4082680pgn.94.2023.02.21.08.51.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Feb 2023 08:51:49 -0800 (PST) Date: Tue, 21 Feb 2023 06:51:48 -1000 From: Tejun Heo To: Jason Gunthorpe Cc: Michal Hocko , Yosry Ahmed , Alistair Popple , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, 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: DB5B1C0004 X-Stat-Signature: jzdk1r9z7uu8o7ueendsomnhj67f8cka X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1676998311-885256 X-HE-Meta: U2FsdGVkX19A1Y4du/+ChO4v00pHifCGkvU5Gt/gHKy9rgyPfb/lrhUVielbP+4+I462RKOSwSkUXtBV+dIZD3L5OgbIt5vHiYq/UaggHfJMNU6RtvmJT05/SY2EhHjisr9Rx/JJyyW8hkPsfEKt6Ze3uz4/cdiQYHqN0Li2VdqijigmbHsIqDOMS/jQwkAWeLv9UznCg5LTBU47PtgKLtfVN5lQRY6y3dEEfxQbXnSMoXLrEkjuvsC3uQW0NRnUSc+aJFM5s+SY4ktxx572vqEJVR0QX2DPjqaKAoj8bMfy6IQlY6/u/tD1FoXnW1vGO1qFnd0lnVxH/RHjLYcDmNjWj1eU9dRj1qux5YuBMvP195LK1VEq2jz9mhj1ljRXtfTpHP7VsYBfCpmmC3g8K3cfr0goZ5PHJhAfFxxiy6fwb2JEV8mCtAxMyTwW4Abh8W9WMH6HZc8AzDgc3+sVzUV1cvCBuKkaXeKsSKePfXKTOIpDDIgukFjEXT/iXiR+y8U8OA0E9Q5CjTwST6zR1V7HMcV3BIqgoELGe0r9I+BOYP9VMjRtDkFqB18PKDaQIGds09dJWNqpWahhBIR2gbQ45s2hMS1OqW5zBNcs/L7SxT5ciu1eRmjAUyZUukHEuFrpdN1n1AekYkEQ2OHht1td8vmEM4kikCTqthwx20aNkjbJqozYvW/PTeQFAz2HCBPvNUXCeoPq880BDgNUSJgfVuaK+Y6jvIq06buZXX3RymbrFCHUcClLMnpOV5CzRu58sj635W0hYVZzYS94pKgnY88k/Jv54THFpyv4WQkXGh18av1cVPPl9HIZPp0Nd3KmJjsn7W36NCe1cK420MIGcn7JzMgnZIlN96Y0GDDZ/ztTVoLXXpWoUsyZT9N1u3AMLEqplpzt3fbfuIYTXlUs0ewWCNE5Bvm6OuWPxcvAt3VySt+cE97wt0fDvuXZ7EUd+JV5CkAMFzdCqwr NsAnEumU ogFm13XsOd+0g5I/yXKAea3WX/YHsovH2svaQNfPh9k/Dvf5G21VIAhY2c7iVaENCKz023DLz+rf5OfYBI5joZbwAsBrwh3Ur5DKmSGRuGDB2TwWprP6I9ZSeYio17+3OmW8UFzGjbhlL75GY+hwDqBe6CT0j//KznnXI/ULqMi+K6eLGTK/bH7No/1oI7qiF0QIcCW//uWRNFLX8Mu6sjLhAgghxusnkY9bx5d4Yc67Vv8p3ugRIVt/ocFxrGzF0Ii1rSaqd2Khw0s3gDai+0efhnWYtbO3xTPmFI4gNzysYAi0Vp/fOSaYBChdIBeHlnVyAzoEes53kt3dAkZYuftoV87TTECKIpoN4kHEx0IZtf9l/MDiqZ2+RiMR6bUDZb8Vz/BvNUvnUS28lQNDpvNqyVw+VrL9JXZPB9dIMjgLG8CSOnr1uoi1eheU6KFONUf7xsYgRdf2+hFq1Yh21nG91q4qUiAJK2CaKf74DyqqF/r/g3vPIN3pOGA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, On Thu, Feb 16, 2023 at 08:45:38AM -0400, Jason Gunthorpe wrote: > On Thu, Feb 16, 2023 at 09:04:03AM +0100, Michal Hocko wrote: > > > > In most cases the ownship traces back to a file descriptor. When the > > > file is closed the pin goes away. > > > > This assumes a specific use of {un}pin_user_page*, right? IIUC the > > cgroup charging is meant to be used from vm_account but that doesn't > > really tell anything about the lifetime nor the ownership. Maybe this is > > just a matter of documentation update... > > Yes documentation. > > > > > The interface itself doesn't talk about > > > > anything like that and so it seems perfectly fine to unpin from a > > > > completely different context then pinning. > > > > > > Yes, concievably the close of the FD can be in a totally different > > > process with a different cgroup. > > > > Wouldn't you get an unbalanced charges then? How can admin recover that > > situation? > > No, the approach in this patch series captures the cgroup that was > charged and stores it in the FD until uncharge. > > This is the same as we do today for rlimit. The user/process that is > charged is captured and the uncharge always applies to user/process > that was charged, not the user/process that happens to be associated > with the uncharging context. > > cgroup just add another option so it is user/process/cgroup that can > hold the charge. > > It is conceptually similar to how each struct page has the memcg that > its allocation was charged to - we just record this in the FD not the > page. I don't have a lot of context here but it looks like the problem here is that the newly proposed controller is introducing an ownership discrepancy. If a memory which is pinned by a cgroup is to be charged to the owner of the fd, the memory which isn't pinned should be charged to the memcg of the same cgroup, right? It makes little sense to me to separate the owner of the memory page and the pinner of it. They should be one and the same. Alistair, can you please elaborate how these pages are allocated, charged and used? Thanks. -- tejun