public inbox for amd-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
To: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
Cc: "Michel D�nzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 1/3] drm/ttm: fix ttm_bo_bulk_move_helper
Date: Sat, 8 Sep 2018 15:54:14 +0800	[thread overview]
Message-ID: <20180908075412.GA12334@hr-amur2> (raw)
In-Reply-To: <24dbe7c4-63df-b8a7-28c3-df0e9866841f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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

On Fri, Sep 07, 2018 at 07:18:59PM +0800, Christian K�nig wrote:
> Am 07.09.2018 um 13:02 schrieb Huang, Ray:
> 
>              Yes, that was one problem. Another was that the cutting code was buggy 
>               and determined one of the positions to cut at the wrong time.
> 
>     I went through again about the list cutting behavior and wrote down with the attached picture.
>     After do the second list_cut_position, the list2 should be point the end of "before" list. And list2 won't be used anymore after list cutting. May I know am I something missed? 
> 
> 
> Let's take a look at the original code:
> 
>     list1 = is_swap ? &pos->last->swap : &pos->last->lru;
>     list2 = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
>      
>     list_cut_position(&entries, lru, list1);
>     list_cut_position(&before, &entries, list2);
> 
> 
> As far as I can see the problem is that the first list_cur_position could
> modify the value of pos->first->lru.prev and so make the second
> list_cut_position work on the wrong position.
> 

I think I understood. In this case (the first element of LRU ==
pos->first->lru), please see the picture. If we store first->lru.prev as
list2(LRU head), after do list cutting, the first->lru.prev will overwrite
as new head (entries), however, the orignal list2 will still point previous
head (that is the wrong position now). We actually expected to use the
latest first->lru.prev as the second cutting position. So we should adjust
code sequence like below:

list1 = is_swap ? &pos->last->swap : &pos->last->lru;
list_cut_position(&entries, lru, list1);

list2 = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
list_cut_position(&before, &entries, list2);

Am I understanding right?

Thanks,
Ray

> Regards,
> Christian.
> 
> 
> 
>     Thanks,
>     Ray
> 
>     From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org>
>     Sent: Thursday, September 6, 2018 6:06 PM
>     To: Huang, Ray
>     Cc: Michel Dänzer; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>     Subject: Re: [PATCH 1/3] drm/ttm: fix ttm_bo_bulk_move_helper
>      
> 
>     Am 06.09.2018 um 12:02 schrieb Huang Rui:
> 
>         On Fri, Aug 31, 2018 at 05:17:33PM +0200, Christian König wrote:
> 
>             Am 31.08.2018 um 17:15 schrieb Michel Dänzer:
> 
>                 On 2018-08-31 3:10 p.m., Christian König wrote:
> 
>                     Staring at the function for six hours, just to essentially move one line
>                     of code.
> 
>                 That sucks, but the commit log should describe what the problem was and
>                 how this patch solves it.
> 
> 
> 
>                     Signed-off-by: Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org>
>                     ---
>                        drivers/gpu/drm/ttm/ttm_bo.c | 13 ++++++++-----
>                        1 file changed, 8 insertions(+), 5 deletions(-)
> 
>                     diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>                     index 35d53d81f486..138c98902033 100644
>                     --- a/drivers/gpu/drm/ttm/ttm_bo.c
>                     +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>                     @@ -250,15 +250,18 @@ EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
>                        static void ttm_bo_bulk_move_helper(struct ttm_lru_bulk_move_pos *pos,
>                                                      struct list_head *lru, bool is_swap)
>                        {
>                     +  struct list_head *list;
>                          LIST_HEAD(entries);
>                          LIST_HEAD(before);
>                     -  struct list_head *list1, *list2;
>                     -  list1 = is_swap ? &pos->last->swap : &pos->last->lru;
>                     -  list2 = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
>                     +  reservation_object_assert_held(pos->last->resv);
>                     +  list = is_swap ? &pos->last->swap : &pos->last->lru;
>                     +  list_cut_position(&entries, lru, list);
>                     +
>                     +  reservation_object_assert_held(pos->first->resv);
>                     +  list = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
>                     +  list_cut_position(&before, &entries, list);
> 
>                 So the problem was that the first list_cut_position call could result in
>                 list2 pointing to la-la-land? Good catch!
> 
>             Yes, exactly. Thought that would be obvious, but going to add that
>             to the commit log.
> 
>             Can I get a tested-by? You where much better at reproducing that than I'm.
> 
> 
>         Michel, Christian, thanks so much to take care of this when I was on
>         vacation. And sorry to let you take a long time for finding the cause.
> 
>         Is that because I didn't hold the resveration before cut the list from
>         position "first" and "last"?
> 
>     Yes, that was one problem. Another was that the cutting code was buggy
>     and determined one of the positions to cut at the wrong time.
> 
> 
>            May I know in which cases, we must hold the
>         bo's reservation firstly?
> 
>     BOs are reserved to prevent moving them. E.g. when the BO isn't reserved
>     it can move around and so the LRU where you want to add/remove it could
>     change.
> 
>     Christian.
> 
> 
>         Thanks,
>         Ray
> 
> 
> 
>     _______________________________________________
>     amd-gfx mailing list
>     amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>     https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
> 
>     amd-gfx Info Page - freedesktop.org
>     lists.freedesktop.org
>     To see the collection of prior postings to the list, visit the amd-gfx Archives.. Using amd-gfx: To post a message to all the list members, send email to amd-gfx-PD4FTy7X32lNgt0PjOBp9xlNPtJONSTn@public.gmane.org You can subscribe to the list, or change your existing subscription, in the sections below.
> 
> 
> 
> 
>    
>     _______________________________________________
>     amd-gfx mailing list
>     amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>     https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
> 

[-- Attachment #2: Wrong_case.jpg --]
[-- Type: image/jpeg, Size: 70757 bytes --]

[-- Attachment #3: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2018-09-08  7:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 13:10 [PATCH 1/3] drm/ttm: fix ttm_bo_bulk_move_helper Christian König
     [not found] ` <20180831131019.2486-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-08-31 13:10   ` [PATCH 2/3] drm/amdgpu: fix "use bulk moves for efficient VM LRU handling" v2 Christian König
     [not found]     ` <20180831131019.2486-2-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-09-03  2:05       ` Zhang, Jerry (Junwei)
2018-08-31 13:10   ` [PATCH 3/3] drm/amdgpu: fix idle state and bulk_moveavle flag Christian König
     [not found]     ` <20180831131019.2486-3-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-08-31 15:19       ` Michel Dänzer
2018-08-31 15:15   ` [PATCH 1/3] drm/ttm: fix ttm_bo_bulk_move_helper Michel Dänzer
     [not found]     ` <a186be44-e64b-f408-fa30-bb81b59322f6-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-08-31 15:17       ` Christian König
     [not found]         ` <c8d0d5c6-1221-26be-4005-2f7ae21ade80-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-09-06 10:02           ` Huang Rui
2018-09-06 10:06             ` Christian König
     [not found]               ` <3be7e67a-2ffe-21c0-2160-69a330413858-5C7GfCeVMHo@public.gmane.org>
2018-09-07 11:02                 ` Huang, Ray
     [not found]                   ` <CY1PR12MB0043539F7EE805B3A98E1FE2EC000-1s8aH8ViOEdbUNsZNX5b0gdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-09-07 11:18                     ` Christian König
     [not found]                       ` <24dbe7c4-63df-b8a7-28c3-df0e9866841f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-09-08  7:54                         ` Huang Rui [this message]
2018-09-08 10:43                           ` Christian König
2018-09-03  2:05   ` Zhang, Jerry (Junwei)

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=20180908075412.GA12334@hr-amur2 \
    --to=ray.huang-5c7gfcevmho@public.gmane.org \
    --cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox