All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"David Airlie" <airlied@linux.ie>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Gert Wollny" <gert.wollny@collabora.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.com>,
	"Daniel Stone" <daniel@fooishbar.org>,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Rob Herring" <robh@kernel.org>,
	"Steven Price" <steven.price@arm.com>,
	"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
	"Emil Velikov" <emil.l.velikov@gmail.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Qiang Yu" <yuq825@gmail.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	"Dmitry Osipenko" <digetx@gmail.com>,
	linux-tegra@vger.kernel.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, kernel@collabora.com
Subject: Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
Date: Fri, 24 Jun 2022 22:21:52 +0200	[thread overview]
Message-ID: <YrYc4IUHJWSbC6AX@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGt61t2truYDCxm17hqUPV-UdEdHjLs+6vmj5RPoPuVBYg@mail.gmail.com>

On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> > +       mutex_unlock(&gem_shrinker->lock);
> 
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing.  Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.

Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.

It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.

> > +               /* prevent racing with the dma-buf importing/exporting */
> > +               if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > +                       *lock_contention |= true;
> > +                       goto resv_unlock;
> > +               }
> 
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported).  So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.

Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: "David Airlie" <airlied@linux.ie>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	dri-devel@lists.freedesktop.org,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Rob Herring" <robh@kernel.org>,
	"Daniel Stone" <daniel@fooishbar.org>,
	"Steven Price" <steven.price@arm.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.com>,
	"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	virtualization@lists.linux-foundation.org,
	"Chia-I Wu" <olvaffe@gmail.com>,
	linux-media@vger.kernel.org, "Daniel Vetter" <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	linaro-mm-sig@lists.linaro.org,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	linux-tegra@vger.kernel.org,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	amd-gfx@lists.freedesktop.org,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Gert Wollny" <gert.wollny@collabora.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Emil Velikov" <emil.l.velikov@gmail.com>,
	linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
	"Qiang Yu" <yuq825@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
Date: Fri, 24 Jun 2022 22:21:52 +0200	[thread overview]
Message-ID: <YrYc4IUHJWSbC6AX@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGt61t2truYDCxm17hqUPV-UdEdHjLs+6vmj5RPoPuVBYg@mail.gmail.com>

On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> > +       mutex_unlock(&gem_shrinker->lock);
> 
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing.  Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.

Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.

It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.

> > +               /* prevent racing with the dma-buf importing/exporting */
> > +               if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > +                       *lock_contention |= true;
> > +                       goto resv_unlock;
> > +               }
> 
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported).  So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.

Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: "David Airlie" <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Steven Price" <steven.price@arm.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.com>,
	"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	virtualization@lists.linux-foundation.org,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	linux-tegra@vger.kernel.org,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	amd-gfx@lists.freedesktop.org,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Gert Wollny" <gert.wollny@collabora.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Emil Velikov" <emil.l.velikov@gmail.com>,
	linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
	"Qiang Yu" <yuq825@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
Date: Fri, 24 Jun 2022 22:21:52 +0200	[thread overview]
Message-ID: <YrYc4IUHJWSbC6AX@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGt61t2truYDCxm17hqUPV-UdEdHjLs+6vmj5RPoPuVBYg@mail.gmail.com>

On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> > +       mutex_unlock(&gem_shrinker->lock);
> 
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing.  Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.

Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.

It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.

> > +               /* prevent racing with the dma-buf importing/exporting */
> > +               if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > +                       *lock_contention |= true;
> > +                       goto resv_unlock;
> > +               }
> 
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported).  So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.

Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: "David Airlie" <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Rob Herring" <robh@kernel.org>,
	"Daniel Stone" <daniel@fooishbar.org>,
	"Steven Price" <steven.price@arm.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.com>,
	"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	virtualization@lists.linux-foundation.org,
	"Chia-I Wu" <olvaffe@gmail.com>,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	"Maxime Ripard" <mripard@kernel.org>,
	linaro-mm-sig@lists.linaro.org,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	linux-tegra@vger.kernel.org,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	amd-gfx@lists.freedesktop.org,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Gert Wollny" <gert.wollny@collabora.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
	"Qiang Yu" <yuq825@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
Date: Fri, 24 Jun 2022 22:21:52 +0200	[thread overview]
Message-ID: <YrYc4IUHJWSbC6AX@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGt61t2truYDCxm17hqUPV-UdEdHjLs+6vmj5RPoPuVBYg@mail.gmail.com>

On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> > +       mutex_unlock(&gem_shrinker->lock);
> 
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing.  Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.

Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.

It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.

> > +               /* prevent racing with the dma-buf importing/exporting */
> > +               if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > +                       *lock_contention |= true;
> > +                       goto resv_unlock;
> > +               }
> 
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported).  So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.

Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: "David Airlie" <airlied@linux.ie>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	dri-devel@lists.freedesktop.org,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Rob Herring" <robh@kernel.org>,
	"Daniel Stone" <daniel@fooishbar.org>,
	"Steven Price" <steven.price@arm.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.com>,
	"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	virtualization@lists.linux-foundation.org,
	"Chia-I Wu" <olvaffe@gmail.com>,
	linux-media@vger.kernel.org, "Daniel Vetter" <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	linaro-mm-sig@lists.linaro.org,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	linux-tegra@vger.kernel.org,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	amd-gfx@lists.freedesktop.org,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Gert Wollny" <gert.wollny@collabora.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Emil Velikov" <emil.l.velikov@gmail.com>,
	linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
	"Qiang Yu" <yuq825@gmail.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
Date: Fri, 24 Jun 2022 22:21:52 +0200	[thread overview]
Message-ID: <YrYc4IUHJWSbC6AX@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGt61t2truYDCxm17hqUPV-UdEdHjLs+6vmj5RPoPuVBYg@mail.gmail.com>

On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> > +       mutex_unlock(&gem_shrinker->lock);
> 
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing.  Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.

Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.

It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.

> > +               /* prevent racing with the dma-buf importing/exporting */
> > +               if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > +                       *lock_contention |= true;
> > +                       goto resv_unlock;
> > +               }
> 
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported).  So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.

Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2022-06-24 20:21 UTC|newest]

Thread overview: 204+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 23:50 [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers Dmitry Osipenko
2022-05-26 23:50 ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 01/22] drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-06-28 20:12   ` Thomas Hellström (Intel)
2022-06-28 20:12     ` Thomas Hellström (Intel)
2022-06-28 20:12     ` [Intel-gfx] " Thomas Hellström (Intel)
2022-06-29  8:23     ` Dmitry Osipenko
2022-06-29  8:23       ` [Intel-gfx] " Dmitry Osipenko
2022-06-29  8:23       ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 02/22] drm/gem: Move mapping of imported dma-bufs to drm_gem_mmap_obj() Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-06-29  6:40   ` Thomas Hellström (Intel)
2022-06-29  6:40     ` [Intel-gfx] " Thomas Hellström (Intel)
2022-06-29  6:40     ` Thomas Hellström (Intel)
2022-06-29  8:22     ` Dmitry Osipenko
2022-06-29  8:22       ` [Intel-gfx] " Dmitry Osipenko
2022-06-29  8:22       ` Dmitry Osipenko
2022-06-29  8:22       ` Dmitry Osipenko
2022-06-29  8:43       ` Thomas Hellström (Intel)
2022-06-29  8:43         ` Thomas Hellström (Intel)
2022-06-29  8:43         ` [Intel-gfx] " Thomas Hellström (Intel)
2022-06-29  8:43         ` Thomas Hellström (Intel)
2022-06-29 23:06         ` Dmitry Osipenko
2022-06-29 23:06           ` [Intel-gfx] " Dmitry Osipenko
2022-06-29 23:06           ` Dmitry Osipenko
2022-06-29 23:06           ` Dmitry Osipenko
2022-07-04 12:33           ` [Linaro-mm-sig] " Christian König
2022-07-04 12:33             ` [Intel-gfx] " Christian König
2022-07-04 12:33             ` Christian König
2022-07-04 12:33             ` Christian König
2022-07-04 12:33             ` Christian König via Virtualization
2022-07-04 22:44             ` Dmitry Osipenko
2022-07-04 22:44               ` [Intel-gfx] " Dmitry Osipenko
2022-07-04 22:44               ` Dmitry Osipenko
2022-07-04 22:44               ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 03/22] drm/panfrost: Put mapping instead of shmem obj on panfrost_mmu_map_fault_addr() error Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 04/22] drm/panfrost: Fix shrinker list corruption by madvise IOCTL Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-27 15:56   ` Alyssa Rosenzweig
2022-05-27 15:56     ` [Intel-gfx] " Alyssa Rosenzweig
2022-05-27 15:56     ` Alyssa Rosenzweig
2022-05-27 15:56     ` Alyssa Rosenzweig
2022-05-30  9:41   ` Steven Price
2022-05-30  9:41     ` [Intel-gfx] " Steven Price
2022-05-30  9:41     ` Steven Price
2022-05-26 23:50 ` [PATCH v6 05/22] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 06/22] drm/virtio: Check whether transferred 2D BO is shmem Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 07/22] drm/virtio: Unlock reservations on virtio_gpu_object_shmem_init() error Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 08/22] drm/virtio: Unlock reservations on dma_resv_reserve_fences() error Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-06-29  6:43   ` Thomas Hellström (Intel)
2022-06-29  6:43     ` [Intel-gfx] " Thomas Hellström (Intel)
2022-06-29  6:43     ` Thomas Hellström (Intel)
2022-05-26 23:50 ` [PATCH v6 09/22] drm/virtio: Use appropriate atomic state in virtio_gpu_plane_cleanup_fb() Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 10/22] drm/shmem-helper: Add missing vunmap on error Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 11/22] drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table() Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 12/22] drm/virtio: Simplify error handling of virtio_gpu_object_create() Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 13/22] drm/virtio: Improve DMA API usage for shmem BOs Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 14/22] dma-buf: Introduce new locking convention Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-27  2:37   ` kernel test robot
2022-05-27 12:44     ` Dmitry Osipenko
2022-05-27 12:44       ` Dmitry Osipenko
2022-05-30  6:50   ` Christian König via Virtualization
2022-05-30  6:50     ` [Intel-gfx] " Christian König
2022-05-30  6:50     ` Christian König
2022-05-30  6:50     ` Christian König
2022-05-30 13:26     ` Dmitry Osipenko
2022-05-30 13:26       ` Dmitry Osipenko
2022-05-30 13:41       ` Christian König via Virtualization
2022-05-30 13:41         ` Christian König
2022-05-30 13:41         ` [Intel-gfx] " Christian König
2022-05-30 13:41         ` Christian König
2022-05-30 13:57         ` Dmitry Osipenko
2022-05-30 13:57           ` Dmitry Osipenko
2022-06-28 21:26           ` Thomas Hellström (Intel)
2022-06-28 21:26             ` Thomas Hellström (Intel)
2022-06-28 21:26             ` [Intel-gfx] " Thomas Hellström (Intel)
2022-07-01 10:43             ` Dmitry Osipenko
2022-07-01 10:43               ` [Intel-gfx] " Dmitry Osipenko
2022-07-01 10:43               ` Dmitry Osipenko
2022-07-04 22:38               ` Dmitry Osipenko
2022-07-04 22:38                 ` [Intel-gfx] " Dmitry Osipenko
2022-07-04 22:38                 ` Dmitry Osipenko
2022-07-04 22:38                 ` Dmitry Osipenko
2022-07-05 10:52                 ` Dmitry Osipenko
2022-07-05 10:52                   ` [Intel-gfx] " Dmitry Osipenko
2022-07-05 10:52                   ` Dmitry Osipenko
2022-07-05 10:52                   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 15/22] drm/shmem-helper: Don't use vmap_use_count for dma-bufs Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 16/22] drm/shmem-helper: Use reservation lock Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-06-05 16:47   ` Daniel Vetter
2022-06-05 16:47     ` Daniel Vetter
2022-06-05 16:47     ` [Intel-gfx] " Daniel Vetter
2022-06-05 16:47     ` Daniel Vetter
2022-06-05 16:47     ` Daniel Vetter
2022-06-05 18:32     ` [Intel-gfx] " Rob Clark
2022-06-05 18:32       ` Rob Clark
2022-06-05 18:32       ` Rob Clark
2022-06-05 18:32       ` Rob Clark
2022-06-05 18:32       ` Rob Clark
2022-06-05 18:45       ` Daniel Vetter
2022-06-05 18:45         ` Daniel Vetter
2022-06-05 18:45         ` [Intel-gfx] " Daniel Vetter
2022-06-05 18:45         ` Daniel Vetter
2022-06-05 18:45         ` Daniel Vetter
2022-06-06 10:57     ` Christian König
2022-06-06 10:57       ` Christian König
2022-06-06 10:57       ` Christian König
2022-06-06 10:57       ` Christian König
2022-06-07 15:33       ` Dmitry Osipenko
2022-06-07 15:33         ` Dmitry Osipenko
2022-06-07 15:33         ` Dmitry Osipenko
2022-06-19 17:53   ` Rob Clark
2022-06-19 17:53     ` Rob Clark
2022-06-19 17:53     ` [Intel-gfx] " Rob Clark
2022-06-19 17:53     ` Rob Clark
2022-06-19 17:53     ` Rob Clark
2022-06-20 14:08     ` Dmitry Osipenko
2022-06-20 14:08       ` Dmitry Osipenko
2022-06-20 14:08       ` Dmitry Osipenko
2022-06-20 15:18       ` Rob Clark
2022-06-20 15:18         ` Rob Clark
2022-06-20 15:18         ` Rob Clark
2022-06-20 15:18         ` [Intel-gfx] " Rob Clark
2022-06-20 15:18         ` Rob Clark
2022-06-24 20:23         ` Daniel Vetter
2022-06-24 20:23           ` Daniel Vetter
2022-06-24 20:23           ` [Intel-gfx] " Daniel Vetter
2022-06-24 20:23           ` Daniel Vetter
2022-06-24 20:23           ` Daniel Vetter
2022-06-24 20:21     ` Daniel Vetter [this message]
2022-06-24 20:21       ` Daniel Vetter
2022-06-24 20:21       ` [Intel-gfx] " Daniel Vetter
2022-06-24 20:21       ` Daniel Vetter
2022-06-24 20:21       ` Daniel Vetter
2022-06-20 15:37   ` Rob Clark
2022-06-20 15:37     ` Rob Clark
2022-06-20 15:37     ` Rob Clark
2022-06-20 15:37     ` Rob Clark
2022-06-20 15:37     ` [Intel-gfx] " Rob Clark
2022-06-21 16:39     ` Dmitry Osipenko
2022-06-21 16:39       ` Dmitry Osipenko
2022-06-21 16:39       ` [Intel-gfx] " Dmitry Osipenko
2022-06-21 16:39       ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 18/22] drm/gem: Add drm_gem_pin_unlocked() Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 19/22] drm/virtio: Support memory shrinking Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 20/22] drm/virtio: Use dev_is_pci() Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 21/22] drm/virtio: Return proper error codes instead of -1 Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 22/22] drm/panfrost: Switch to generic memory shrinker Dmitry Osipenko
2022-05-26 23:50   ` Dmitry Osipenko
2022-05-27 11:48   ` Alyssa Rosenzweig
2022-05-27 11:48     ` [Intel-gfx] " Alyssa Rosenzweig
2022-05-27 11:48     ` Alyssa Rosenzweig
2022-05-27 11:48     ` Alyssa Rosenzweig
2022-06-10 14:40 ` [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers Dmitry Osipenko
2022-06-10 14:40   ` Dmitry Osipenko
2022-06-10 14:40   ` Dmitry Osipenko
2022-06-28 12:31 ` Robin Murphy
2022-06-28 12:31   ` Robin Murphy
2022-06-28 12:31   ` Robin Murphy
2022-06-28 12:50   ` Dmitry Osipenko
2022-06-28 12:50     ` [Intel-gfx] " Dmitry Osipenko
2022-06-28 12:50     ` Dmitry Osipenko
2022-06-28 16:48     ` Rob Clark
2022-06-28 16:48       ` Rob Clark
2022-06-28 16:48       ` Rob Clark
2022-06-28 16:48       ` [Intel-gfx] " Rob Clark
2022-06-28 16:48       ` Rob Clark
2022-06-28 23:11       ` Dmitry Osipenko
2022-06-28 23:11         ` [Intel-gfx] " Dmitry Osipenko
2022-06-28 23:11         ` Dmitry Osipenko
2022-06-28 23:11         ` Dmitry Osipenko
2022-06-28 12:51   ` Dmitry Osipenko
2022-06-28 12:51     ` [Intel-gfx] " Dmitry Osipenko
2022-06-28 12:51     ` Dmitry Osipenko
2022-06-28 13:11   ` Dmitry Osipenko
2022-06-28 13:11     ` [Intel-gfx] " Dmitry Osipenko
2022-06-28 13:11     ` Dmitry Osipenko
2022-05-27 12:21 [PATCH v6 14/22] dma-buf: Introduce new locking convention kernel test robot
2022-05-30  7:05 ` Dan Carpenter
2022-05-27 14:03 [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker kernel test robot
2022-05-30  7:09 ` [kbuild] " Dan Carpenter
2022-05-30  7:09 ` Dan Carpenter
2022-05-30 13:27 ` Dmitry Osipenko
2022-05-30 13:27   ` Dmitry Osipenko

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=YrYc4IUHJWSbC6AX@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel.almeida@collabora.com \
    --cc=daniel@fooishbar.org \
    --cc=digetx@gmail.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=gert.wollny@collabora.com \
    --cc=gurchetansingh@chromium.org \
    --cc=gustavo.padovan@collabora.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kernel@collabora.com \
    --cc=kraxel@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=robdclark@gmail.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=steven.price@arm.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tfiga@chromium.org \
    --cc=thierry.reding@gmail.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=yuq825@gmail.com \
    /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.