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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0CBEC63797 for ; Thu, 12 Jan 2023 07:56:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236843AbjALH4j (ORCPT ); Thu, 12 Jan 2023 02:56:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236676AbjALH4g (ORCPT ); Thu, 12 Jan 2023 02:56:36 -0500 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DD8911837 for ; Wed, 11 Jan 2023 23:56:35 -0800 (PST) Received: by mail-pj1-x1049.google.com with SMTP id fy20-20020a17090b021400b00226f0026263so6815513pjb.2 for ; Wed, 11 Jan 2023 23:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:from:subject:message-id:references:mime-version:in-reply-to:date :from:to:cc:subject:date:message-id:reply-to; bh=Vg6nAgYjZ4wYYlTqMF3jbo791ipG8SuFLzs8v41dmTI=; b=kL0UvQite/urbN7Yp3NlzfzFTECRjRM1K7T5g4ZxG3zHylBlslAyzr6qxrAi9aysJM RDeACOZIgRrgriXoR4Pb3FUm6siAnl76A15BakL+7xmzzyJYvBrIKvFGmqzOdrHuLyHw eLCWL5a84U7mTNiiuZkhyyW//9BsTntHFbTMWG3xqNxmoxumrT4tac24HiqQmCacQxb7 hWUb45XPnPy09DrO6jQeVMIxbVjfhO/QXKCL83ehtKjjTMjBps8fFK6gPa75SmpeTyw8 vcf4DzdsP5Yv5ETLXzCGGp7Lotol2entUVESDqjWMyWKfU3XQsKSss8PleO3BkZomuWi ioIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=Vg6nAgYjZ4wYYlTqMF3jbo791ipG8SuFLzs8v41dmTI=; b=NruvWqfsG+AE3O27DNJQQn+V1nmgsNfPFTyZqJMX+Cqh2XWTAkvelqXki2FWe3K9NL VU9jHqDmDxhGfaTd7kOjsHWM40Wq0Ebp1d7xWOafTLQKSua8tUjaVEIRUpx58/nvjY++ WXUf4H+KYI3pmnQehF4aemb2tmYY0kcM4yHhCDVtvVQGN8CJYE9bHwwTpsuzcwtH9E3c RxQdb3oOGJtLp4fKcQqjqaZFQ0Wq/uq8waqBn1xBJjbqIuqwaO4YRNDL3RgV2H6yL0ln XkVzC5EZGlJ+SYBWlOw/DcoRO6CX7NyLXadCNqNT0xxXkfLp09+adHqSDKkxdXZZp1pk szNw== X-Gm-Message-State: AFqh2kpYGSjF1EZMumXOLso385kgaumgdtqJNuq0AeOlORsx+nARpsfF 419hKRDtGYGr4R5W2u+GvsfJVuZLZ32V4Q== X-Google-Smtp-Source: AMrXdXv29WhmagcsXxW5VJTVWoRrJdV9U6Gev8NYUGOd+PwEKkvAbufkJGb0qU84S3rueo4liZ5Ei6F1OKpY1Q== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a62:1488:0:b0:581:85ab:16b3 with SMTP id 130-20020a621488000000b0058185ab16b3mr4558933pfu.67.1673510194669; Wed, 11 Jan 2023 23:56:34 -0800 (PST) Date: Thu, 12 Jan 2023 07:56:31 +0000 In-Reply-To: Mime-Version: 1.0 References: <20230109213809.418135-1-tjmercier@google.com> Message-ID: <20230112075631.wc6fd54ci55drhkp@google.com> Subject: Re: [PATCH 0/4] Track exported dma-buffers with memcg From: Shakeel Butt To: "T.J. Mercier" , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Greg Kroah-Hartman , "Arve =?utf-8?B?SGrDuG5uZXbDpWc=?=" , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Carlos Llamas , Suren Baghdasaryan , Sumit Semwal , "Christian =?utf-8?B?S8O2bmln?=" , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , android-mm@google.com, jstultz@google.com, 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, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: On Wed, Jan 11, 2023 at 11:56:45PM +0100, Daniel Vetter wrote: > [...] > I think eventually, at least for other "account gpu stuff in cgroups" use > case we do want to actually charge the memory. > > The problem is a bit that with gpu allocations reclaim is essentially "we > pass the error to userspace and they get to sort the mess out". There are > some exceptions (some gpu drivers to have shrinkers) would we need to make > sure these shrinkers are tied into the cgroup stuff before we could enable > charging for them? > No, there is no requirement to have shrinkers or making such memory reclaimable before charging it. Though existing shrinkers and the possible future shrinkers would need to be converted into memcg aware shrinkers. Though there will be a need to update user expectations that if they use memcgs with hard limits, they may start seeing memcg OOMs after the charging of dmabuf. > Also note that at least from the gpu driver side this is all a huge > endeavour, so if we can split up the steps as much as possible (and get > something interim useable that doesn't break stuff ofc), that is > practically need to make headway here. This sounds reasonable to me.