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 D3889C433EF for ; Wed, 30 Mar 2022 20:56:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348425AbiC3U6Y (ORCPT ); Wed, 30 Mar 2022 16:58:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351271AbiC3U6I (ORCPT ); Wed, 30 Mar 2022 16:58:08 -0400 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15256140E4 for ; Wed, 30 Mar 2022 13:56:22 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id a17so25900419edm.9 for ; Wed, 30 Mar 2022 13:56:22 -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; bh=nrCvj7Yq7SSib6FwgrmdzFU7UXWII5P9ju8EtUscCW0=; b=boNOk7s9MFWRe9Q5TIHyCBcLZAL3UIEBNmLOOWFhXw6emE+CwKKHdvhC0KffHeh0nF M6pQueP4aCRuJFI7dDzsd8w7oMHmH5zQ1LRTPvQqJiDWbX35wE19ft4HqpfvXL9C1Got NCX+Q7kxCou/I+IrAEJ9Str9SLE8Vpfu1F+nizveKZzqZBmp0ZbLt4163c8iNRc9oq8L +OvcysVAV7F4grrtlsY0RpODotiBIJhRyklfusZBaq0zNt0ADmOlhrzyjpVkba5kg+sN XtIoUFtjlMDxb5pCPzyxnwJLsJ9yaQfPKTqYXEV4ifVXSG43LsveuoFab9UFC5oCyEkr VAUA== 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; bh=nrCvj7Yq7SSib6FwgrmdzFU7UXWII5P9ju8EtUscCW0=; b=au3YgTcMEZOizBJUtes3JDT0x4OGEGCa97mX677Fdiev2Ilwbt0F4xgculYAlqLoyR rXHzyvn4njSbFf+HxlECC5dhnBWCM02W7SulAgpj95S5JCk8GvJHiiN1kmhuJ39lEe72 eThNeO/tk/1wQTI0+zYog9qryPb8pJMfT9/4BuyqashVNUypTf4pKr1pVkcScQPO7JUG NI6kLLrC76Q6YEkeEmhL87z/xUbj4/VI2VzcYem2pPgTeF/JYNFPH93drPSQ+maqYmkL PkfWOcCYX56rwhEt8J0vGKxcUueMKSEIb6pyrzuQJBSWLZlGjWWOJG2ITJoCt0ZlpqE+ flZQ== X-Gm-Message-State: AOAM531mktu+qkieKWROLcX/uhWuvaJ5wXgNDwrRxtOGdCwYpwmqWG5R 0Ktnd4+h5306pesz19uXI7VRFfXMvvIQZbTo9WtZsg== X-Google-Smtp-Source: ABdhPJxrjw92bYCs2jMACCLJM4/KOh2wxHOU9997F7UwcQsMWyUFgKpYWFcmr9tg4GWCYtbl/45JU/IvvXHerOIfRxk= X-Received: by 2002:a05:6402:3452:b0:418:f963:42a3 with SMTP id l18-20020a056402345200b00418f96342a3mr13302952edc.12.1648673780493; Wed, 30 Mar 2022 13:56:20 -0700 (PDT) MIME-Version: 1.0 References: <20220328035951.1817417-1-tjmercier@google.com> <20220328035951.1817417-3-tjmercier@google.com> In-Reply-To: From: "T.J. Mercier" Date: Wed, 30 Mar 2022 13:56:09 -0700 Message-ID: Subject: Re: [RFC v4 2/8] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory To: Tejun Heo 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 , Zefan Li , Johannes Weiner , Shuah Khan , Kalesh Singh , Kenny.Ho@amd.com, =?UTF-8?Q?Michal_Koutn=C3=BD?= , 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" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Mar 29, 2022 at 9:59 AM Tejun Heo wrote: > > Hello, I'm sorry for the delay Tejun, my test device stopped working and my attention has been occupied with that. > > On Mon, Mar 28, 2022 at 03:59:41AM +0000, T.J. Mercier wrote: > > The API/UAPI can be extended to set per-device/total allocation limits > > in the future. > > This total thing kinda bothers me. Can you please provide some concrete > examples of how this and per-device limits would be used? The use case we have for accounting the total (separate from the individual devices) is to include the value as part of bugreports, for understanding the system-wide amount of dmabuf allocations. I'm not aware of an existing need to limit the total. Admittedly this is just the sum over the devices, but we currently maintain out of tree code to do this sort of thing today. [1] The per-device limits would be used to restrict the amount of each type of allocation charged to an individual application to prevent hogging or to completely prevent access. This limitation is not something we have implemented today, but it is on our roadmap. [1] https://android-review.googlesource.com/c/kernel/common/+/1566704/3/drivers/dma-buf/dma-heap.c > > Thanks. > > -- > tejun