All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Feng Tang <feng.tang@intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Rong Chen <rong.a.chen@intel.com>,
	michel@daenzer.net, linux-kernel@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	ying.huang@intel.com, lkp@01.org
Subject: Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Date: Mon, 26 Aug 2019 12:50:50 +0200	[thread overview]
Message-ID: <1b897bfe-fd40-3ae3-d867-424d1fc08c44@suse.de> (raw)
In-Reply-To: <20190824051605.GA63850@shbuild999.sh.intel.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 6473 bytes --]

Hi Feng

Am 24.08.19 um 07:16 schrieb Feng Tang:
> Hi Thomas,
> 
> On Thu, Aug 22, 2019 at 07:25:11PM +0200, Thomas Zimmermann wrote:
>> Hi
>> 
>> I was traveling and could reply earlier. Sorry for taking so long.
> 
> No problem! I guessed so :)
> 
>> 
>> Am 13.08.19 um 11:36 schrieb Feng Tang:
>>> Hi Thomas,
>>> 
>>> On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote:
>>>> Hi Thomas,
>>>> 
>>>> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote:
>>>>> Hi,
>>>>> 
>>>>>>> Actually we run the benchmark as a background process, do
>>>>>>> we need to disable the cursor and test again?
>>>>>> There's a worker thread that updates the display from the 
>>>>>> shadow buffer. The blinking cursor periodically triggers 
>>>>>> the worker thread, but the actual update is just the size 
>>>>>> of one character.
>>>>>> 
>>>>>> The point of the test without output is to see if the 
>>>>>> regression comes from the buffer update (i.e., the memcpy 
>>>>>> from shadow buffer to VRAM), or from the worker thread. If
>>>>>>  the regression goes away after disabling the blinking 
>>>>>> cursor, then the worker thread is the problem. If it 
>>>>>> already goes away if there's simply no output from the 
>>>>>> test, the screen update is the problem. On my machine I 
>>>>>> have to disable the blinking cursor, so I think the worker
>>>>>>  causes the performance drop.
>>>>> 
>>>>> We disabled redirecting stdout/stderr to /dev/kmsg,  and the
>>>>>  regression is gone.
>>>>> 
>>>>> commit: f1f8555dfb9 drm/bochs: Use shadow buffer for bochs 
>>>>> framebuffer console 90f479ae51a drm/mgag200: Replace struct 
>>>>> mga_fbdev with generic framebuffer emulation
>>>>> 
>>>>> f1f8555dfb9a70a2  90f479ae51afa45efab97afdde 
>>>>> testcase/testparams/testbox ---------------- 
>>>>> -------------------------- --------------------------- 
>>>>> %stddev      change         %stddev \          | \ 43785 
>>>>> 44481 vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 
>>>>> 43785 44481        GEO-MEAN vm-scalability.median
>>>> 
>>>> Till now, from Rong's tests: 1. Disabling cursor blinking 
>>>> doesn't cure the regression. 2. Disabling printint test results
>>>> to console can workaround the regression.
>>>> 
>>>> Also if we set the perfer_shadown to 0, the regression is also 
>>>> gone.
>>> 
>>> We also did some further break down for the time consumed by the 
>>> new code.
>>> 
>>> The drm_fb_helper_dirty_work() calls sequentially 1. 
>>> drm_client_buffer_vmap	  (290 us) 2. 
>>> drm_fb_helper_dirty_blit_real  (19240 us) 3. 
>>> helper->fb->funcs->dirty()    ---> NULL for mgag200 driver 4. 
>>> drm_client_buffer_vunmap       (215 us)
>>> 
>> 
>> It's somewhat different to what I observed, but maybe I just 
>> couldn't reproduce the problem correctly.
>> 
>>> The average run time is listed after the function names.
>>> 
>>> From it, we can see drm_fb_helper_dirty_blit_real() takes too 
>>> long time (about 20ms for each run). I guess this is the root 
>>> cause of this regression, as the original code doesn't use this 
>>> dirty worker.
>> 
>> True, the original code uses a temporary buffer, but updates the 
>> display immediately.
>> 
>> My guess is that this could be a caching problem. The worker runs 
>> on a different CPU, which doesn't have the shadow buffer in cache.
> 
> Yes, that's my thought too. I profiled the working set size, for most
> of the drm_fb_helper_dirty_blit_real(), it will update a buffer 
> 4096x768(3 MB), and as it is called 30~40 times per second, it surely
> will affect the cache.
> 
> 
>>> As said in last email, setting the prefer_shadow to 0 can avoid 
>>> the regrssion. Could it be an option?
>> 
>> Unfortunately not. Without the shadow buffer, the console's
>> display buffer permanently resides in video memory. It consumes
>> significant amount of that memory (say 8 MiB out of 16 MiB). That
>> doesn't leave enough room for anything else.
>> 
>> The best option is to not print to the console.
> 
> Do we have other options here?

I attached two patches. Both show an improvement in my setup at least.
Could you please test them independently from each other and report back?

prefetch.patch prefetches the shadow buffer two scanlines ahead during
the blit function. The idea is to have the scanlines in cache when they
are supposed to go to hardware.

schedule.patch schedules the dirty worker on the current CPU core (i.e.,
the one that did the drawing to the shadow buffer). Hopefully the shadow
buffer remains in cache meanwhile.

Best regards
Thomas

> My thought is this is clearly a regression, that the old driver
> works fine, while the new version in linux-next doesn't. Also for a
> frame buffer console, writting dozens line of message to it is not a
> rare user case. We have many test platforms
> (servers/desktops/laptops) with different kinds of GFX hardwares, and
> this model works fine for many years :)
> 
> Thanks, Feng
> 
> 
> 
>> Best regards Thomas
>> 
>>> Thanks, Feng
>>> 
>>>> 
>>>> --- a/drivers/gpu/drm/mgag200/mgag200_main.c +++ 
>>>> b/drivers/gpu/drm/mgag200/mgag200_main.c @@ -167,7 +167,7 @@ 
>>>> int mgag200_driver_load(struct drm_device *dev, unsigned long 
>>>> flags) dev->mode_config.preferred_depth = 16; else 
>>>> dev->mode_config.preferred_depth = 32; - 
>>>> dev->mode_config.prefer_shadow = 1; + 
>>>> dev->mode_config.prefer_shadow = 0;
>>>> 
>>>> And from the perf data, one obvious difference is good case 
>>>> don't call drm_fb_helper_dirty_work(), while bad case calls.
>>>> 
>>>> Thanks, Feng
>>>> 
>>>>> Best Regards, Rong Chen
>>> _______________________________________________ dri-devel mailing
>>> list dri-devel@lists.freedesktop.org 
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>> 
>> 
>> -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, 
>> Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, 
>> Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
>> 
> 
> 
> 
> _______________________________________________ dri-devel mailing 
> list dri-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: prefetch.patch --]
[-- Type: text/x-patch; name="prefetch.patch", Size: 1057 bytes --]

From 7258064b16ab4f44db708670f63c88db8b3f2eea Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 26 Aug 2019 09:53:38 +0200
Subject: prefetch shadow buffer two lines ahead of blit offset

---
 drivers/gpu/drm/drm_fb_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..61cf436840c7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -33,6 +33,7 @@
 #include <linux/dma-buf.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/prefetch.h>
 #include <linux/slab.h>
 #include <linux/sysrq.h>
 #include <linux/vmalloc.h>
@@ -390,6 +391,8 @@ static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
 	unsigned int y;
 
 	for (y = clip->y1; y < clip->y2; y++) {
+		if (y < clip->y2 - 2)
+			prefetch_range(src + 2 * fb->pitches[0], len);
 		memcpy(dst, src, len);
 		src += fb->pitches[0];
 		dst += fb->pitches[0];
-- 
2.22.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.3: schedule.patch --]
[-- Type: text/x-patch; name="schedule.patch", Size: 1012 bytes --]

From 60d5322ae3ab2a4c82c1579b37c34abb3b8222f0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 26 Aug 2019 12:17:38 +0200
Subject: schedule dirty worker on local core

---
 drivers/gpu/drm/drm_fb_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..9abc950cfae2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -34,6 +34,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/slab.h>
+#include <linux/smp.h>
 #include <linux/sysrq.h>
 #include <linux/vmalloc.h>
 
@@ -642,7 +643,7 @@ static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y,
 	clip->y2 = max_t(u32, clip->y2, y + height);
 	spin_unlock_irqrestore(&helper->dirty_lock, flags);
 
-	schedule_work(&helper->dirty_work);
+	schedule_work_on(smp_processor_id(), &helper->dirty_work);
 }
 
 /**
-- 
2.22.0


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: lkp@lists.01.org
Subject: Re: [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Date: Mon, 26 Aug 2019 12:50:50 +0200	[thread overview]
Message-ID: <1b897bfe-fd40-3ae3-d867-424d1fc08c44@suse.de> (raw)
In-Reply-To: <20190824051605.GA63850@shbuild999.sh.intel.com>

[-- Attachment #1: Type: text/plain, Size: 6477 bytes --]

Hi Feng

Am 24.08.19 um 07:16 schrieb Feng Tang:
> Hi Thomas,
> 
> On Thu, Aug 22, 2019 at 07:25:11PM +0200, Thomas Zimmermann wrote:
>> Hi
>> 
>> I was traveling and could reply earlier. Sorry for taking so long.
> 
> No problem! I guessed so :)
> 
>> 
>> Am 13.08.19 um 11:36 schrieb Feng Tang:
>>> Hi Thomas,
>>> 
>>> On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote:
>>>> Hi Thomas,
>>>> 
>>>> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote:
>>>>> Hi,
>>>>> 
>>>>>>> Actually we run the benchmark as a background process, do
>>>>>>> we need to disable the cursor and test again?
>>>>>> There's a worker thread that updates the display from the 
>>>>>> shadow buffer. The blinking cursor periodically triggers 
>>>>>> the worker thread, but the actual update is just the size 
>>>>>> of one character.
>>>>>> 
>>>>>> The point of the test without output is to see if the 
>>>>>> regression comes from the buffer update (i.e., the memcpy 
>>>>>> from shadow buffer to VRAM), or from the worker thread. If
>>>>>>  the regression goes away after disabling the blinking 
>>>>>> cursor, then the worker thread is the problem. If it 
>>>>>> already goes away if there's simply no output from the 
>>>>>> test, the screen update is the problem. On my machine I 
>>>>>> have to disable the blinking cursor, so I think the worker
>>>>>>  causes the performance drop.
>>>>> 
>>>>> We disabled redirecting stdout/stderr to /dev/kmsg,  and the
>>>>>  regression is gone.
>>>>> 
>>>>> commit: f1f8555dfb9 drm/bochs: Use shadow buffer for bochs 
>>>>> framebuffer console 90f479ae51a drm/mgag200: Replace struct 
>>>>> mga_fbdev with generic framebuffer emulation
>>>>> 
>>>>> f1f8555dfb9a70a2  90f479ae51afa45efab97afdde 
>>>>> testcase/testparams/testbox ---------------- 
>>>>> -------------------------- --------------------------- 
>>>>> %stddev      change         %stddev \          | \ 43785 
>>>>> 44481 vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 
>>>>> 43785 44481        GEO-MEAN vm-scalability.median
>>>> 
>>>> Till now, from Rong's tests: 1. Disabling cursor blinking 
>>>> doesn't cure the regression. 2. Disabling printint test results
>>>> to console can workaround the regression.
>>>> 
>>>> Also if we set the perfer_shadown to 0, the regression is also 
>>>> gone.
>>> 
>>> We also did some further break down for the time consumed by the 
>>> new code.
>>> 
>>> The drm_fb_helper_dirty_work() calls sequentially 1. 
>>> drm_client_buffer_vmap	  (290 us) 2. 
>>> drm_fb_helper_dirty_blit_real  (19240 us) 3. 
>>> helper->fb->funcs->dirty()    ---> NULL for mgag200 driver 4. 
>>> drm_client_buffer_vunmap       (215 us)
>>> 
>> 
>> It's somewhat different to what I observed, but maybe I just 
>> couldn't reproduce the problem correctly.
>> 
>>> The average run time is listed after the function names.
>>> 
>>> From it, we can see drm_fb_helper_dirty_blit_real() takes too 
>>> long time (about 20ms for each run). I guess this is the root 
>>> cause of this regression, as the original code doesn't use this 
>>> dirty worker.
>> 
>> True, the original code uses a temporary buffer, but updates the 
>> display immediately.
>> 
>> My guess is that this could be a caching problem. The worker runs 
>> on a different CPU, which doesn't have the shadow buffer in cache.
> 
> Yes, that's my thought too. I profiled the working set size, for most
> of the drm_fb_helper_dirty_blit_real(), it will update a buffer 
> 4096x768(3 MB), and as it is called 30~40 times per second, it surely
> will affect the cache.
> 
> 
>>> As said in last email, setting the prefer_shadow to 0 can avoid 
>>> the regrssion. Could it be an option?
>> 
>> Unfortunately not. Without the shadow buffer, the console's
>> display buffer permanently resides in video memory. It consumes
>> significant amount of that memory (say 8 MiB out of 16 MiB). That
>> doesn't leave enough room for anything else.
>> 
>> The best option is to not print to the console.
> 
> Do we have other options here?

I attached two patches. Both show an improvement in my setup at least.
Could you please test them independently from each other and report back?

prefetch.patch prefetches the shadow buffer two scanlines ahead during
the blit function. The idea is to have the scanlines in cache when they
are supposed to go to hardware.

schedule.patch schedules the dirty worker on the current CPU core (i.e.,
the one that did the drawing to the shadow buffer). Hopefully the shadow
buffer remains in cache meanwhile.

Best regards
Thomas

> My thought is this is clearly a regression, that the old driver
> works fine, while the new version in linux-next doesn't. Also for a
> frame buffer console, writting dozens line of message to it is not a
> rare user case. We have many test platforms
> (servers/desktops/laptops) with different kinds of GFX hardwares, and
> this model works fine for many years :)
> 
> Thanks, Feng
> 
> 
> 
>> Best regards Thomas
>> 
>>> Thanks, Feng
>>> 
>>>> 
>>>> --- a/drivers/gpu/drm/mgag200/mgag200_main.c +++ 
>>>> b/drivers/gpu/drm/mgag200/mgag200_main.c @@ -167,7 +167,7 @@ 
>>>> int mgag200_driver_load(struct drm_device *dev, unsigned long 
>>>> flags) dev->mode_config.preferred_depth = 16; else 
>>>> dev->mode_config.preferred_depth = 32; - 
>>>> dev->mode_config.prefer_shadow = 1; + 
>>>> dev->mode_config.prefer_shadow = 0;
>>>> 
>>>> And from the perf data, one obvious difference is good case 
>>>> don't call drm_fb_helper_dirty_work(), while bad case calls.
>>>> 
>>>> Thanks, Feng
>>>> 
>>>>> Best Regards, Rong Chen
>>> _______________________________________________ dri-devel mailing
>>> list dri-devel(a)lists.freedesktop.org 
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>> 
>> 
>> -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, 
>> Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, 
>> Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
>> 
> 
> 
> 
> _______________________________________________ dri-devel mailing 
> list dri-devel(a)lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: prefetch.patch --]
[-- Type: text/x-patch, Size: 1024 bytes --]

From 7258064b16ab4f44db708670f63c88db8b3f2eea Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 26 Aug 2019 09:53:38 +0200
Subject: prefetch shadow buffer two lines ahead of blit offset

---
 drivers/gpu/drm/drm_fb_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..61cf436840c7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -33,6 +33,7 @@
 #include <linux/dma-buf.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/prefetch.h>
 #include <linux/slab.h>
 #include <linux/sysrq.h>
 #include <linux/vmalloc.h>
@@ -390,6 +391,8 @@ static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
 	unsigned int y;
 
 	for (y = clip->y1; y < clip->y2; y++) {
+		if (y < clip->y2 - 2)
+			prefetch_range(src + 2 * fb->pitches[0], len);
 		memcpy(dst, src, len);
 		src += fb->pitches[0];
 		dst += fb->pitches[0];
-- 
2.22.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: schedule.patch --]
[-- Type: text/x-patch, Size: 979 bytes --]

From 60d5322ae3ab2a4c82c1579b37c34abb3b8222f0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 26 Aug 2019 12:17:38 +0200
Subject: schedule dirty worker on local core

---
 drivers/gpu/drm/drm_fb_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..9abc950cfae2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -34,6 +34,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/slab.h>
+#include <linux/smp.h>
 #include <linux/sysrq.h>
 #include <linux/vmalloc.h>
 
@@ -642,7 +643,7 @@ static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y,
 	clip->y2 = max_t(u32, clip->y2, y + height);
 	spin_unlock_irqrestore(&helper->dirty_lock, flags);
 
-	schedule_work(&helper->dirty_work);
+	schedule_work_on(smp_processor_id(), &helper->dirty_work);
 }
 
 /**
-- 
2.22.0


[-- Attachment #4: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-08-26 10:50 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29  9:51 [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression kernel test robot
2019-07-29  9:51 ` kernel test robot
2019-07-30 17:50 ` Thomas Zimmermann
2019-07-30 17:50   ` Thomas Zimmermann
2019-07-30 18:12   ` Daniel Vetter
2019-07-30 18:12     ` Daniel Vetter
2019-07-30 18:50     ` Thomas Zimmermann
2019-07-30 18:50       ` Thomas Zimmermann
2019-07-30 18:59       ` Daniel Vetter
2019-07-30 18:59         ` Daniel Vetter
2019-07-30 20:26         ` Dave Airlie
2019-07-30 20:26           ` Dave Airlie
2019-07-31  8:13           ` Daniel Vetter
2019-07-31  8:13             ` Daniel Vetter
2019-07-31  9:25             ` [LKP] " Huang, Ying
2019-07-31  9:25               ` Huang, Ying
2019-07-31 10:12               ` [LKP] " Thomas Zimmermann
2019-07-31 10:12                 ` Thomas Zimmermann
2019-07-31 10:21               ` [LKP] " Michel Dänzer
2019-08-01  6:19                 ` Rong Chen
2019-08-01  6:19                   ` Rong Chen
2019-08-01  8:37                   ` [LKP] " Feng Tang
2019-08-01  8:37                     ` Feng Tang
2019-08-01  9:59                     ` [LKP] " Thomas Zimmermann
2019-08-01  9:59                       ` Thomas Zimmermann
2019-08-01 11:25                       ` [LKP] " Feng Tang
2019-08-01 11:25                         ` Feng Tang
2019-08-01 11:58                         ` [LKP] " Thomas Zimmermann
2019-08-01 11:58                           ` Thomas Zimmermann
2019-08-02  7:11                           ` [LKP] " Rong Chen
2019-08-02  7:11                             ` Rong Chen
2019-08-02  8:23                             ` [LKP] " Thomas Zimmermann
2019-08-02  8:23                               ` Thomas Zimmermann
2019-08-02  9:20                             ` [LKP] " Thomas Zimmermann
2019-08-02  9:20                               ` Thomas Zimmermann
2019-08-01  9:57                   ` [LKP] " Thomas Zimmermann
2019-08-01  9:57                     ` Thomas Zimmermann
2019-08-01 13:30                   ` [LKP] " Michel Dänzer
2019-08-02  8:17                     ` Thomas Zimmermann
2019-08-02  8:17                       ` Thomas Zimmermann
2019-07-31 10:10             ` Thomas Zimmermann
2019-07-31 10:10               ` Thomas Zimmermann
2019-08-02  9:11               ` Daniel Vetter
2019-08-02  9:11                 ` Daniel Vetter
2019-08-02  9:26                 ` Thomas Zimmermann
2019-08-02  9:26                   ` Thomas Zimmermann
2019-08-04 18:39   ` Thomas Zimmermann
2019-08-04 18:39     ` Thomas Zimmermann
2019-08-05  7:02     ` Feng Tang
2019-08-05  7:02       ` Feng Tang
2019-08-05  7:28       ` Rong Chen
2019-08-05 10:25         ` Thomas Zimmermann
2019-08-05 10:25           ` Thomas Zimmermann
2019-08-06 12:59           ` [LKP] " Chen, Rong A
2019-08-06 12:59             ` Chen, Rong A
2019-08-07 10:42             ` [LKP] " Thomas Zimmermann
2019-08-07 10:42               ` Thomas Zimmermann
2019-08-09  8:12               ` [LKP] " Rong Chen
2019-08-09  8:12                 ` Rong Chen
2019-08-12  7:25                 ` [LKP] " Feng Tang
2019-08-12  7:25                   ` Feng Tang
2019-08-13  9:36                   ` [LKP] " Feng Tang
2019-08-13  9:36                     ` Feng Tang
2019-08-13  9:36                     ` [LKP] " Feng Tang
2019-08-16  6:55                     ` Feng Tang
2019-08-16  6:55                       ` Feng Tang
2019-08-22 17:25                     ` [LKP] " Thomas Zimmermann
2019-08-22 17:25                       ` Thomas Zimmermann
2019-08-22 17:25                       ` [LKP] " Thomas Zimmermann
2019-08-22 20:02                       ` Dave Airlie
2019-08-22 20:02                         ` Dave Airlie
2019-08-23  9:54                         ` [LKP] " Thomas Zimmermann
2019-08-23  9:54                           ` Thomas Zimmermann
2019-08-23  9:54                           ` [LKP] " Thomas Zimmermann
2019-08-24  5:16                       ` Feng Tang
2019-08-24  5:16                         ` Feng Tang
2019-08-24  5:16                         ` [LKP] " Feng Tang
2019-08-26 10:50                         ` Thomas Zimmermann [this message]
2019-08-26 10:50                           ` Thomas Zimmermann
2019-08-27 12:33                           ` [LKP] " Chen, Rong A
2019-08-27 12:33                             ` Chen, Rong A
2019-08-27 12:33                             ` [LKP] " Chen, Rong A
2019-08-27 17:16                             ` Thomas Zimmermann
2019-08-27 17:16                               ` Thomas Zimmermann
2019-08-28  9:37                               ` [LKP] " Rong Chen
2019-08-28  9:37                                 ` Rong Chen
2019-08-28 10:51                                 ` [LKP] " Thomas Zimmermann
2019-08-28 10:51                                   ` Thomas Zimmermann
2019-09-04  6:27                                   ` [LKP] " Feng Tang
2019-09-04  6:27                                     ` Feng Tang
2019-09-04  6:53                                     ` [LKP] " Thomas Zimmermann
2019-09-04  6:53                                       ` Thomas Zimmermann
2019-09-04  8:11                                       ` [LKP] " Daniel Vetter
2019-09-04  8:11                                         ` Daniel Vetter
2019-09-04  8:35                                         ` [LKP] " Feng Tang
2019-09-04  8:35                                           ` Feng Tang
2019-09-04  8:43                                           ` [LKP] " Thomas Zimmermann
2019-09-04  8:43                                             ` Thomas Zimmermann
2019-09-04 14:30                                             ` [LKP] " Chen, Rong A
2019-09-04 14:30                                               ` Chen, Rong A
2019-09-04  9:17                                           ` [LKP] " Daniel Vetter
2019-09-04  9:17                                             ` Daniel Vetter
2019-09-04 11:15                                             ` [LKP] " Dave Airlie
2019-09-04 11:15                                               ` Dave Airlie
2019-09-04 11:20                                               ` [LKP] " Daniel Vetter
2019-09-04 11:20                                                 ` Daniel Vetter
2019-09-04 11:20                                                 ` [LKP] " Daniel Vetter
2019-09-05  6:59                                                 ` Feng Tang
2019-09-05  6:59                                                   ` Feng Tang
2019-09-05 10:37                                                   ` [LKP] " Daniel Vetter
2019-09-05 10:37                                                     ` Daniel Vetter
2019-09-05 10:48                                                     ` [LKP] " Feng Tang
2019-09-05 10:48                                                       ` Feng Tang
2019-09-05 10:48                                                       ` [LKP] " Feng Tang
2019-09-09 14:12                                     ` Thomas Zimmermann
2019-09-09 14:12                                       ` Thomas Zimmermann
2019-09-09 14:12                                       ` [LKP] " Thomas Zimmermann
2019-09-16  9:06                                       ` Feng Tang
2019-09-16  9:06                                         ` Feng Tang
2019-09-17  8:48                                         ` [LKP] " Thomas Zimmermann
2019-09-17  8:48                                           ` Thomas Zimmermann
2019-09-17  8:48                                           ` [LKP] " Thomas Zimmermann
2019-08-05 10:22       ` Thomas Zimmermann
2019-08-05 10:22         ` Thomas Zimmermann
2019-08-05 12:52         ` Feng Tang
2019-08-05 12:52           ` Feng Tang
2020-01-06 13:19           ` Thomas Zimmermann
2020-01-06 13:19             ` Thomas Zimmermann
2020-01-08  2:25             ` Rong Chen
2020-01-08  2:28               ` Rong Chen
2020-01-08  5:20               ` Thomas Zimmermann
2020-01-08  5:20                 ` Thomas Zimmermann

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=1b897bfe-fd40-3ae3-d867-424d1fc08c44@suse.de \
    --to=tzimmermann@suse.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=feng.tang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=michel@daenzer.net \
    --cc=rong.a.chen@intel.com \
    --cc=sfr@canb.auug.org.au \
    --cc=ying.huang@intel.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.