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 964B6C54EB4 for ; Tue, 24 Jan 2023 19:46:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A0996B0071; Tue, 24 Jan 2023 14:46:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 129776B0072; Tue, 24 Jan 2023 14:46:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0BBD6B0073; Tue, 24 Jan 2023 14:46:34 -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 DB28E6B0071 for ; Tue, 24 Jan 2023 14:46:34 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 75296140C96 for ; Tue, 24 Jan 2023 19:46:34 +0000 (UTC) X-FDA: 80390724708.24.E5F25DA Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf17.hostedemail.com (Postfix) with ESMTP id 8EB8F4001A for ; Tue, 24 Jan 2023 19:46:32 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=s+S6NvSt; spf=pass (imf17.hostedemail.com: domain of 3lzXQYwgKCGgYNGQKKRHMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--shakeelb.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3lzXQYwgKCGgYNGQKKRHMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--shakeelb.bounces.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=1674589592; 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=/GyNyIeeVhsFfDVzo3Uv5K6TJGpkGDF80R1/yVGfsGs=; b=3oqn3f8+VCDnCRDoA5DnL6ewZnXVmy6i8o6KfSVblx9fOuGNvEHcaBXtSgeEe2B+s4M6gD mXN7mCe7Y8pdUPDk2fFafcvYm8INkuxsUh+UMJdgo5CoNBzvIW3NSmu4pU/ZXqq/ggEBwV yv+VACJrH3sx1MDcf8q2WuA8hGku+K8= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=s+S6NvSt; spf=pass (imf17.hostedemail.com: domain of 3lzXQYwgKCGgYNGQKKRHMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--shakeelb.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3lzXQYwgKCGgYNGQKKRHMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674589592; a=rsa-sha256; cv=none; b=ptbgenRA8aDFEuhrbhQ2StE5XtHjA51I8ykgOGLcPcSuBBIgENckgmmyhnduAcViPYjUtd ze2j15SVa+g97gVHX51HwJCf9yiNGvGxUBB1+1SFwCSIChlHE31lisUwMmpzci1AIHiTUd V0rzQbem4VG6BHr4/dyI07Gi3JIoHKU= Received: by mail-pf1-f201.google.com with SMTP id s4-20020a056a00194400b0058d9b9fecb6so7169690pfk.1 for ; Tue, 24 Jan 2023 11:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=/GyNyIeeVhsFfDVzo3Uv5K6TJGpkGDF80R1/yVGfsGs=; b=s+S6NvStNDfxmLH+7HdkNoMxBGNFu15nS1JbU3o7kKshlx447vodpqXHX0di6WuhDZ a1MO4rwyUgw2LrSCtGq08zPjHV51A98+yZHCXgSTngUgV4XXVXDeDPcjG7CuFBAKTuAR kTHeE5yNP/OikYuovflyL/aEcJ+JOgjIm+SFfej2Z5ILJ8d5oy9l9Ll/yZqUaJp+iWXi DD5HNZQ0qbq4VEtW0G8okZMv8molLKQ44+tNH1Nu8KJ7B9jWjxkED24jWjgeRCFRcQ8I izZ99IapQOypOy9ZAzpJglu0Rf0PFoxX1xa78gNX6tsRtckWTeEuw1Q3Oze2b7gqQYar JRcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/GyNyIeeVhsFfDVzo3Uv5K6TJGpkGDF80R1/yVGfsGs=; b=WCIZo5R5hzQFqjd700IV8Y5Hk6U9oimXYA2DbE/aEhhslxag+bXKN9mXjXs9+yN8/B jjU25wlnEqoKezf6Ppyaumxk6ExnbqiZ4fR135ZisZfVVbSzO/onN/ZbpIHjCJgAFp+p jzCj6FoPcm4LdBaFSB0KCPVSJqNxcqcjOO/RHCGm3ZNEPlvlhsGW4md2buHSAPyCkuHI sFev4DsixHr0XMayaxj47p4unhY40WJQ+3la5KKvlWY6XdH61KkvrnPNoRQXrer6uPV+ MAEK1zToXsuROSG2ForoHvDHS4uM7MWS5MjaWh3BrC0r6WALmaOOIBwOioFPti7QnWJW lOeA== X-Gm-Message-State: AFqh2kqk2X/LaMtggLrgB16YaJybIgLOwXUwKcbU7X0ohjPQq77a2hHy z8jWKJAP3aP1WwdrucKb7k8nQuw0JuNyBQ== X-Google-Smtp-Source: AMrXdXukkwsl/ioqg+fD35BqMTHaPjz5qGGy0gbqkxllMlQZ94JVGByIXE/sjuoEMUouo8MXOIoUEVSlfpldQQ== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a62:30c7:0:b0:58d:af10:5831 with SMTP id w190-20020a6230c7000000b0058daf105831mr2987930pfw.24.1674589591181; Tue, 24 Jan 2023 11:46:31 -0800 (PST) Date: Tue, 24 Jan 2023 19:46:28 +0000 In-Reply-To: Mime-Version: 1.0 References: <20230123191728.2928839-1-tjmercier@google.com> <20230123191728.2928839-2-tjmercier@google.com> Message-ID: <20230124194628.d44rtcfsv23fndxw@google.com> Subject: Re: [PATCH v2 1/4] memcg: Track exported dma-buffers From: Shakeel Butt To: Michal Hocko Cc: "T.J. Mercier" , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Sumit Semwal , "Christian =?utf-8?B?S8O2bmln?=" , Roman Gushchin , Muchun Song , Andrew Morton , daniel.vetter@ffwll.ch, android-mm@google.com, jstultz@google.com, jeffv@google.com, cmllamas@google.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org Content-Type: text/plain; charset="us-ascii" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8EB8F4001A X-Stat-Signature: e4m7n6151ndt4m7wxc84da9t1m4eid4k X-HE-Tag: 1674589592-967759 X-HE-Meta: U2FsdGVkX1+3xQLZASF5zZW77Wi/+UnmpayysuB7E+g33l8mdre//edlgDGd1rSNMF4nuf22VW2ajC4/3lSYPFp97caFlfpLs8M6iE2meW5reSi9kuJvVdhGQZlZlM48xqTI27rHD4XBZnt1jK8+LIMM92uXjyl392T6Lkz5YPueMuGZQGLUZViIkVpBX6CoYbj53InlQrgcqW8fdfMIDwvQFk1H16YZ1CyaCSEKR0lVWHCCLd7g9EJd4G0Dq9Pau29Hvk58KulDpjKVFNKlDtuplZb1lm5rsReFSRZ0MZKRZtCX6JIJ0rGxgM/62k9byjZ6gjiA617tYQlMu6t5VpgNoP4H8Cg8Q8+n6CebGBTSIzg2qBbJJcR6TlJPp559xOv7PIUkFr6ip3j8+B5WZVvJrD8gZHlnoenMvUcvjPHOgD0Zx3hiwjztM0a4eOY+1/xLWJMzvnJJQcHPrFm6LGeMOphelSYvTpB2qU48cNdMpVGvJEei+sCZUTGroru1lZhbtOSy4gX+e3diNKR9o5T82TRe9r2SKXoyiiFIDoXehsDPMyd4llaquZvhNJfL8Sw9xk9QVsT/1NnURJQLFf8+nvrMA8EZ0zNYq47CaACCyyQeXG/oJrW4xNSn/5awyLeFtuvSxFh2jOUvJ1mC+dCmn/u4Ee/xiP+MM/AbgGJ6ZLzy1qRbiWGQEG2EUgA1Dcl/s+DWEqf5Tp56NBv45gMXDEPQVU038c7zjhMyfQamuULRREIoOA7+WBPxrftc5sepHiOoqVrG61zJT+atozisNINUsI5UFA54I9VcPqn6RokashdJPcUen+2vy/xBJWwUl6WF13GazyOZaYB51ja0aCzbDlqPD0CjDPzA3y2aXabxNsDODD7fyGlqZpSU2ZRJIehD31Jo4wSxwFQeADU9yWTpVUwB8Lu5p5aABfnUnOsWwoX528W7qj37Qtd/DJSOmCCDF4+RYYoYOTP MAorq7sG 8vNysco4J/h8BIp5rDBZITXrhXZHBIXwppUGUp6o2lfe4nU6EFpNf2bClLF2ai9f768Vuu8TEWFvkx12AU/5qoV4UkMkVjwno1Il6A64ogC9NAr/PnryKNIi7H7DTOmH5yOfvwB30khKMLAdxzuZJazLy6LmrTvJLxZPiAM0hDKcBi/XTo/FSTc7Xe5JUgn/PcAXZoqHH4IM/NnjcccYFPvyMsqVF89OOWEbthRJ6qxpFsZNoMzbb7jz5CkEIdftNiOH6GhOkj7L2ixWikHQ3UPXYZ+VS+qB8TFIvBdd+6rRla78aSeCoeVJ78/0X2jNQ9T6rg3J427L4ND11DPeNH+WjD4xiQUOOtGgKdXvdWVovnA9uStUWToJH2EqnxOQYrS6qFsYxxcIsh4AI0RAnhevTfURRXP7KzGfo7+YhiSibTMJySlQgCieU4EYGb2Ra1+KIote+Kzrae1hQzXrV8FBmQcO1nKRi4DDKfVOj4Z7W9uCK+t27tN4mUhB3eO5W861qiXm/HYQ1Oh7mJtOQ87VONFR0ifN2rtVgMIROUoe7a63U94Ra6lVvMvDGH4/wtarRFSPkaP3kPZdXyA/XD0w8nmlrCaC0471FAqKNqEgm+CkFHhkYvoUx/Q== 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 Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote: > On Mon 23-01-23 19:17:23, T.J. Mercier wrote: > > When a buffer is exported to userspace, use memcg to attribute the > > buffer to the allocating cgroup until all buffer references are > > released. > > Is there any reason why this memory cannot be charged during the > allocation (__GFP_ACCOUNT used)? > Also you do charge and account the memory but underlying pages do not > know about their memcg (this is normally done with commit_charge for > user mapped pages). This would become a problem if the memory is > migrated for example. I don't think this is movable memory. > This also means that you have to maintain memcg > reference outside of the memcg proper which is not really nice either. > This mimicks tcp kmem limit implementation which I really have to say I > am not a great fan of and this pattern shouldn't be coppied. > I think we should keep the discussion on technical merits instead of personal perference. To me using skmem like interface is totally fine but the pros/cons need to be very explicit and the clear reasons to select that option should be included. To me there are two options: 1. Using skmem like interface as this patch series: The main pros of this option is that it is very simple. Let me list down the cons of this approach: a. There is time window between the actual memory allocation/free and the charge and uncharge and [un]charge happen when the whole memory is allocated or freed. I think for the charge path that might not be a big issue but on the uncharge, this can cause issues. The application and the potential shrinkers have freed some of this dmabuf memory but until the whole dmabuf is freed, the memcg uncharge will not happen. This can consequences on reclaim and oom behavior of the application. b. Due to the usage model i.e. a central daemon allocating the dmabuf memory upfront, there is a requirement to have a memcg charge transfer functionality to transfer the charge from the central daemon to the client applications. This does introduce complexity and avenues of weird reclaim and oom behavior. 2. Allocate and charge the memory on page fault by actual user In this approach, the memory is not allocated upfront by the central daemon but rather on the page fault by the client application and the memcg charge happen at the same time. The only cons I can think of is this approach is more involved and may need some clever tricks to track the page on the free patch i.e. we to decrement the dmabuf memcg stat on free path. Maybe a page flag. The pros of this approach is there is no need have a charge transfer functionality and the charge/uncharge being closely tied to the actual memory allocation and free. Personally I would prefer the second approach but I don't want to just block this work if the dmabuf folks are ok with the cons mentioned of the first approach. thanks, Shakeel