lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 4 Apr 2022 10:49:12 -0700 From: "T.J. Mercier" <tjmercier@...gle.com> To: Tejun Heo <tj@...nel.org> Cc: David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, Jonathan Corbet <corbet@....net>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arve Hjønnevåg <arve@...roid.com>, Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>, Joel Fernandes <joel@...lfernandes.org>, Christian Brauner <brauner@...nel.org>, Hridya Valsaraju <hridya@...gle.com>, Suren Baghdasaryan <surenb@...gle.com>, Sumit Semwal <sumit.semwal@...aro.org>, Christian König <christian.koenig@....com>, Benjamin Gaignard <benjamin.gaignard@...aro.org>, Liam Mark <lmark@...eaurora.org>, Laura Abbott <labbott@...hat.com>, Brian Starkey <Brian.Starkey@....com>, John Stultz <john.stultz@...aro.org>, Zefan Li <lizefan.x@...edance.com>, Johannes Weiner <hannes@...xchg.org>, Shuah Khan <shuah@...nel.org>, Kalesh Singh <kaleshsingh@...gle.com>, Kenny.Ho@....com, Michal Koutný <mkoutny@...e.com>, Shuah Khan <skhan@...uxfoundation.org>, dri-devel@...ts.freedesktop.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org, cgroups@...r.kernel.org, linux-kselftest@...r.kernel.org Subject: Re: [RFC v4 2/8] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory On Mon, Apr 4, 2022 at 10:42 AM Tejun Heo <tj@...nel.org> wrote: > > Hello, > > On Wed, Mar 30, 2022 at 01:56:09PM -0700, T.J. Mercier wrote: > > 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] > > So, drop this part? Ok, will do - I'll drop the "total" limitation text from the series. > > Thanks. > > -- > tejun
Powered by blists - more mailing lists