All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <brauner@kernel.org>,
	"Hridya Valsaraju" <hridya@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@redhat.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <john.stultz@linaro.org>,
	"Tejun Heo" <tj@kernel.org>, "Zefan Li" <lizefan.x@bytedance.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Kalesh Singh" <kaleshsingh@google.com>,
	Kenny.Ho@amd.com, 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
Subject: Re: [RFC v3 1/8] gpu: rfc: Proposal for a GPU cgroup controller
Date: Wed, 23 Mar 2022 11:40:20 +0100	[thread overview]
Message-ID: <20220323104020.GI8477@blackbody.suse.cz> (raw)
In-Reply-To: <CABdmKX10jqubJr49JENaHpFnqHV88+Fb7iNZNH4T1Cy7n9y=ag@mail.gmail.com>

On Tue, Mar 22, 2022 at 08:41:55AM -0700, "T.J. Mercier" <tjmercier@google.com> wrote:
> So "total" is used twice here in two different contexts.
> The first one is the global "GPU" cgroup context. As in any buffer
> that any exporter claims is a GPU buffer, regardless of where/how it
> is allocated. So this refers to the sum of all gpu buffers of any
> type/source. An exporter contributes to this total by registering a
> corresponding gpucg_device and making charges against that device when
> it exports.
> The second one is in a per device context. This allows us to make a
> distinction between different types of GPU memory based on who
> exported the buffer. A single process can make use of several
> different types of dma buffers (for example cached and uncached
> versions of the same type of memory), and it would be useful to have
> different limits for each. These are distinguished by the device name
> string chosen when the gpucg_device is first registered.

So is this understanding correct?

(if there was an analogous line in gpu.memory.current to gpu.memory.max)
	$ cat gpu.memory.current
	total T
	dev1  d1
	...
	devN  dn

T = Σ di + RAM_backed_buffers

and that some of RAM_backed_buffers may be accounted also in
memory.current (case by case, depending on allocator).

Thanks,
Michal


WARNING: multiple messages have this Message-ID (diff)
From: "Michal Koutný" <mkoutny@suse.com>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: "Zefan Li" <lizefan.x@bytedance.com>,
	linux-doc@vger.kernel.org, "David Airlie" <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Kalesh Singh" <kaleshsingh@google.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	Kenny.Ho@amd.com, "Jonathan Corbet" <corbet@lwn.net>,
	"Martijn Coenen" <maco@android.com>,
	"Laura Abbott" <labbott@redhat.com>,
	linux-media@vger.kernel.org, linux-kselftest@vger.kernel.org,
	"Todd Kjos" <tkjos@android.com>,
	linaro-mm-sig@lists.linaro.org, "Tejun Heo" <tj@kernel.org>,
	cgroups@vger.kernel.org, "Suren Baghdasaryan" <surenb@google.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, "Liam Mark" <lmark@codeaurora.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Hridya Valsaraju" <hridya@google.com>
Subject: Re: [RFC v3 1/8] gpu: rfc: Proposal for a GPU cgroup controller
Date: Wed, 23 Mar 2022 11:40:20 +0100	[thread overview]
Message-ID: <20220323104020.GI8477@blackbody.suse.cz> (raw)
In-Reply-To: <CABdmKX10jqubJr49JENaHpFnqHV88+Fb7iNZNH4T1Cy7n9y=ag@mail.gmail.com>

On Tue, Mar 22, 2022 at 08:41:55AM -0700, "T.J. Mercier" <tjmercier@google.com> wrote:
> So "total" is used twice here in two different contexts.
> The first one is the global "GPU" cgroup context. As in any buffer
> that any exporter claims is a GPU buffer, regardless of where/how it
> is allocated. So this refers to the sum of all gpu buffers of any
> type/source. An exporter contributes to this total by registering a
> corresponding gpucg_device and making charges against that device when
> it exports.
> The second one is in a per device context. This allows us to make a
> distinction between different types of GPU memory based on who
> exported the buffer. A single process can make use of several
> different types of dma buffers (for example cached and uncached
> versions of the same type of memory), and it would be useful to have
> different limits for each. These are distinguished by the device name
> string chosen when the gpucg_device is first registered.

So is this understanding correct?

(if there was an analogous line in gpu.memory.current to gpu.memory.max)
	$ cat gpu.memory.current
	total T
	dev1  d1
	...
	devN  dn

T = Σ di + RAM_backed_buffers

and that some of RAM_backed_buffers may be accounted also in
memory.current (case by case, depending on allocator).

Thanks,
Michal


WARNING: multiple messages have this Message-ID (diff)
From: "Michal Koutný" <mkoutny@suse.com>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <brauner@kernel.org>,
	"Hridya Valsaraju" <hridya@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Liam Mark" <lmark@codeaurora.org>
Subject: Re: [RFC v3 1/8] gpu: rfc: Proposal for a GPU cgroup controller
Date: Wed, 23 Mar 2022 11:40:20 +0100	[thread overview]
Message-ID: <20220323104020.GI8477@blackbody.suse.cz> (raw)
In-Reply-To: <CABdmKX10jqubJr49JENaHpFnqHV88+Fb7iNZNH4T1Cy7n9y=ag@mail.gmail.com>

On Tue, Mar 22, 2022 at 08:41:55AM -0700, "T.J. Mercier" <tjmercier@google.com> wrote:
> So "total" is used twice here in two different contexts.
> The first one is the global "GPU" cgroup context. As in any buffer
> that any exporter claims is a GPU buffer, regardless of where/how it
> is allocated. So this refers to the sum of all gpu buffers of any
> type/source. An exporter contributes to this total by registering a
> corresponding gpucg_device and making charges against that device when
> it exports.
> The second one is in a per device context. This allows us to make a
> distinction between different types of GPU memory based on who
> exported the buffer. A single process can make use of several
> different types of dma buffers (for example cached and uncached
> versions of the same type of memory), and it would be useful to have
> different limits for each. These are distinguished by the device name
> string chosen when the gpucg_device is first registered.

So is this understanding correct?

(if there was an analogous line in gpu.memory.current to gpu.memory.max)
	$ cat gpu.memory.current
	total T
	dev1  d1
	...
	devN  dn

T = Σ di + RAM_backed_buffers

and that some of RAM_backed_buffers may be accounted also in
memory.current (case by case, depending on allocator).

Thanks,
Michal


  reply	other threads:[~2022-03-23 10:40 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 16:52 [RFC v3 0/8] Proposal for a GPU cgroup controller T.J. Mercier
2022-03-09 16:52 ` T.J. Mercier
2022-03-09 16:52 ` T.J. Mercier
2022-03-09 16:52 ` [RFC v3 1/8] gpu: rfc: " T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-21 17:37   ` Michal Koutný
2022-03-21 17:37     ` Michal Koutný
2022-03-21 17:37     ` Michal Koutný
2022-03-22 15:41     ` T.J. Mercier
2022-03-22 15:41       ` T.J. Mercier
2022-03-22 15:41       ` T.J. Mercier
2022-03-23 10:40       ` Michal Koutný [this message]
2022-03-23 10:40         ` Michal Koutný
2022-03-23 10:40         ` Michal Koutný
2022-03-09 16:52 ` [RFC v3 2/8] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52 ` [RFC v3 3/8] dmabuf: Use the GPU cgroup charge/uncharge APIs T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52 ` [RFC v3 4/8] dmabuf: heaps: export system_heap buffers with GPU cgroup charging T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52 ` [RFC v3 5/8] dmabuf: Add gpu cgroup charge transfer function T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-21 17:45   ` Michal Koutný
2022-03-21 17:45     ` Michal Koutný
2022-03-21 17:45     ` Michal Koutný
2022-03-21 23:54     ` T.J. Mercier
2022-03-21 23:54       ` T.J. Mercier
2022-03-21 23:54       ` T.J. Mercier
2022-03-09 16:52 ` [RFC v3 6/8] binder: Add a buffer flag to relinquish ownership of fds T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-15  0:50   ` Todd Kjos
2022-03-15  0:50     ` Todd Kjos
2022-03-15  0:50     ` Todd Kjos
2022-03-09 16:52 ` [RFC v3 7/8] binder: use __kernel_pid_t and __kernel_uid_t for userspace T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-10 19:33   ` Todd Kjos
2022-03-10 19:33     ` Todd Kjos
2022-03-10 19:33     ` Todd Kjos
2022-03-14 23:45     ` T.J. Mercier
2022-03-14 23:45       ` T.J. Mercier
2022-03-14 23:45       ` T.J. Mercier
2022-03-15  0:11       ` Todd Kjos
2022-03-15  0:11         ` Todd Kjos
2022-03-15  0:11         ` Todd Kjos
2022-03-15  7:56       ` David Laight
2022-03-15  7:56         ` David Laight
2022-03-15  7:56         ` David Laight
2022-03-15 19:02         ` T.J. Mercier
2022-03-15 19:02           ` T.J. Mercier
2022-03-15 19:02           ` T.J. Mercier
2022-03-09 16:52 ` [RFC v3 8/8] selftests: Add binder cgroup gpu memory transfer test T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 16:52   ` T.J. Mercier
2022-03-09 21:31   ` Shuah Khan
2022-03-09 21:31     ` Shuah Khan
2022-03-09 21:31     ` Shuah Khan
2022-03-15  0:11     ` T.J. Mercier
2022-03-15  0:11       ` T.J. Mercier
2022-03-15  0:11       ` T.J. Mercier
2022-03-15  0:43   ` Todd Kjos
2022-03-15  0:43     ` Todd Kjos
2022-03-15  0:43     ` Todd Kjos
2022-03-22 16:07     ` Christian Brauner
2022-03-22 16:07       ` Christian Brauner
2022-03-22 16:07       ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220323104020.GI8477@blackbody.suse.cz \
    --to=mkoutny@suse.com \
    --cc=Brian.Starkey@arm.com \
    --cc=Kenny.Ho@amd.com \
    --cc=airlied@linux.ie \
    --cc=arve@android.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=brauner@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hridya@google.com \
    --cc=joel@joelfernandes.org \
    --cc=john.stultz@linaro.org \
    --cc=kaleshsingh@google.com \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=lmark@codeaurora.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maco@android.com \
    --cc=mripard@kernel.org \
    --cc=shuah@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=tjmercier@google.com \
    --cc=tkjos@android.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.