Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3422394pxb; Mon, 4 Apr 2022 16:30:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz66cf7xSsslGdBbDyWZYGlOVrwxfQhttvjXOwF2pb1893N3/FOUws04DKRYcb8c2EkLQ6w X-Received: by 2002:a17:902:ec81:b0:156:5b17:5cb5 with SMTP id x1-20020a170902ec8100b001565b175cb5mr655275plg.38.1649115041034; Mon, 04 Apr 2022 16:30:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649115041; cv=none; d=google.com; s=arc-20160816; b=QEYtDYuwEe6ZfrckzhiWnsW2LcprRrZhapH92fm3wCTwMAi7wb04MlKwuqZUqM1nF8 b80LPgLjXFnw/Des6mZFunGWwjlBIyuUjEN6BmgA8BdKYPprXJLYm/qpgsnIaFcUSx99 DtdMp1ZuExK1RjDupRul6LUpDJAQRh/hlQEGxHARTtZfiEHNSjt76MxuMgsckovyUhKo wk2mxmkLImB4Rb2jind8YQhPFzdsH/I2+IjWk4yMKBaPuNYhw+4A2wLnM2Mi7TXZLDk1 tggZSxYWaMJiM8cq6I94I7eJo7R2RNY68CPKlOuVSbROZ+r+YBplVtD7ObSnn09Ky+ew XSTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=DLtOWenxXCw5vQfabcGIJp+Je2gVQjc6VzKW0XdhyiQ=; b=ZwtqCm8WmFxLeoPgTWg+P+2ecujKno5cAaHsBsJxOsy895K+trVrsHwEZgUwhjGPXq 9g+p4b/ir183dGTFk+eN+BKUYWx0L6zlj70CPree3lVMHYozJDv15BIB5V5hqcLumVy+ UIvIHq9Kl3Fa21y0fn3Wmih/SEomyFrOMHAWe0OzuzkJLHqxHvwIuy8ektvd6zRCu//3 z110yNHD/2yiKyQ5P4Hury9qAT9kjjABassGOzpgNC/uogHz+JWCwxte6hNWLYxtAhYF QZopNbmytmxBm6PqDiBMbvw7TztxrsRgzF/ihYGzmKz5n8EMDjMYWc0KUA+HqXxCPVbT hzyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=h+rLLWbM; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id w5-20020a6556c5000000b003827f206120si11429142pgs.73.2022.04.04.16.30.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 16:30:41 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=h+rLLWbM; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9828CC7C; Mon, 4 Apr 2022 16:28:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244281AbiDASnq (ORCPT + 99 others); Fri, 1 Apr 2022 14:43:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349997AbiDASnk (ORCPT ); Fri, 1 Apr 2022 14:43:40 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC3D9215936 for ; Fri, 1 Apr 2022 11:41:50 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id dr20so7599622ejc.6 for ; Fri, 01 Apr 2022 11:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DLtOWenxXCw5vQfabcGIJp+Je2gVQjc6VzKW0XdhyiQ=; b=h+rLLWbMQ/iHnS5/pj19fhLvsaEM9Wtdy1qxj2U1tvLPMxqJCjQosFe2F24w4FuEik zSrjnDN8RVUqsGTehE0RLFU9iAnAgsZLy6+HaVFpgiQgyaH0bi2nNoUnW/PN++7erDWp RX2laVeByhssITiwvlf5JqxR9o7iIybqO73rq6iDBg0II0FI27oeey/L41eoch8FqdX9 HSLjysJJ9QsP1Keic9p/q3hcmxjndegS2Td9/sQ/qsgWCFS7CVf9el3ursRzkfzAihRs Haf70E3SoFpNKPytMrE2H1AsOY13tYTorkjDKu54Gzzinf56UPzglOwHHVZBMjHJCiR4 t3yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DLtOWenxXCw5vQfabcGIJp+Je2gVQjc6VzKW0XdhyiQ=; b=ymAWtn8GFzugSV6mquWoehIvLej/VQlNFdUTrICCwlpOFSe+7zyiLmUQ+NRk39oa38 /82PVIDnP9qbBxzGRaB0GBLCebw2XhW9wlahOJ786KxNQaFGJSsWWDrequpq/PD3Yem6 jN40jeye/OQbiA/jJaZdnxghOfiusMxUc+HtGg+NUtW4W1NwLrRl1JjceAP1FyWJaqZo XYcsbo8JP4zzVNsokeQA3nFpLEd4puhqVXDnYp0RnQYuRda6LGW0p0H+vkQ2yIeZybq2 Ie7F6qywDJE9LiS2ts1ICXy6DhXAAexF6W1TlE1KjOROEUBVjG/ET524lMFQ2YsSZMnC 95Dg== X-Gm-Message-State: AOAM530nVJ7IOFh6eK+fUTYS/FxBvwSjYLqV4zcwZ/5iIGCGRzgvHncN ikgEnrTmlgso850qSrlmRuJpIYCTUKFMW//+hqWP+Q== X-Received: by 2002:a17:907:3eaa:b0:6df:b058:96a with SMTP id hs42-20020a1709073eaa00b006dfb058096amr1028056ejc.368.1648838508127; Fri, 01 Apr 2022 11:41:48 -0700 (PDT) MIME-Version: 1.0 References: <20220328035951.1817417-1-tjmercier@google.com> <20220328035951.1817417-6-tjmercier@google.com> <20220329152142.GA15794@blackbody.suse.cz> In-Reply-To: <20220329152142.GA15794@blackbody.suse.cz> From: "T.J. Mercier" Date: Fri, 1 Apr 2022 11:41:36 -0700 Message-ID: Subject: Re: [RFC v4 5/8] dmabuf: Add gpu cgroup charge transfer function To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: David Airlie , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jonathan Corbet , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Suren Baghdasaryan , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , John Stultz , Tejun Heo , Zefan Li , Johannes Weiner , Shuah Khan , Kalesh Singh , Kenny.Ho@amd.com, Shuah Khan , dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 29, 2022 at 8:21 AM Michal Koutn=C3=BD wrote= : > > Hi. > > On Mon, Mar 28, 2022 at 03:59:44AM +0000, "T.J. Mercier" wrote: > > From: Hridya Valsaraju > > > > The dma_buf_charge_transfer function provides a way for processes to > > (s/dma_bug_charge_transfer/dma_bug_transfer_charge/) > Doh! Thanks. > > transfer charge of a buffer to a different process. This is essential > > for the cases where a central allocator process does allocations for > > various subsystems, hands over the fd to the client who requested the > > memory and drops all references to the allocated memory. > > I understood from [1] some buffers are backed by regular RAM. How are > these charges going to be transferred (if so)? > This link doesn't work for me, but I think you're referring to the discussion about your "RAM_backed_buffers" comment from March 23rd. I wanted to do a simple test to confirm my own understanding here, but that got delayed due to some problems on my end. Anyway the test I did goes like this: enable memcg and gpu cgoups tracking and run a process that allocates 100MiB of dmabufs. Observe memcg and gpu accounting values before and after the allocation. Before # cat memory.current gpu.memory.current 14909440 system 0 After # cat memory.current gpu.memory.current 48025600 system 104857600 So the memcg value increases by about 30 MiB while the gpu values increases by 100 MiB. This is with kmem enabled, and the /proc/maps file for this process indicates that the majority of that 30 MiB is kernel memory. I think this result shows that neither the kernel nor process memory overlap with the gpu cgroup tracking of these allocations. So despite the fact that these buffers are in main memory, they are allocated in a way that does not result in memcg attribution. (It looks to me like __GFP_ACCOUNT is not set for these.) > > Thanks, > Michal > > [1] > https://lore.kernel.org/r/CABdmKX2NSAKMC6rReMYfo2SSVNxEXcS466hk3qF6YFt-j-= +_NQ@mail.gmail.com