[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131206001554.GA28698@amt.cnet>
Date: Thu, 5 Dec 2013 22:15:54 -0200
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Xiao Guangrong <xiaoguangrong.eric@...il.com>
Cc: Gleb Natapov <gleb@...hat.com>, avi.kivity@...il.com,
"pbonzini@...hat.com Bonzini" <pbonzini@...hat.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Eric Dumazet <dada1@...mosbay.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3 07/15] KVM: MMU: introduce nulls desc
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
> > Is it not the case that simply moving to the slow path once a maximum of
> > rewalks has been reached enough? (looks a like a good solution).
>
> In some cases, the lockless walker will do endless-walking on desc and
> without rewalk, consider this case:
>
> there are two descs: desc1 and desc2 who is pointed by desc1->next:
> desc1->next = desc2.
>
> CPU 0 CPU 1
>
> lockless walk on desc1
> deleting desc1 from the rmap
> lockless walk on desc2 (desc1->next)
> delete desc2 from the rmap
> add desc1
> add desc2, then desc2->next = desc1
>
> lockless walk on desc1
> delete desc2
> delete desc1
> add desc2
> add desc1; the desc1->next = desc2
> lockless walk on desc2
>
> ……
>
> Then, the walker is endlessly walking on desc1 and desc2 without any rewalk.
Ouch, this is the sort of thing that is worrysome. Do you still think
that having the benefit for shadow is important enough to justify this
complexity?
Also, another separate possibility is to use the dirty bit (which recent
Intel processors support). Then there are no faults at all to handle.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists