It likes nulls list and we use the pte-list as the nulls which can help us to
detect whether the "desc" is moved to anther rmap then we can re-walk the rmap
if that happened
kvm->slots_lock is held when we do lockless walking that prevents rmap
is reused (free rmap need to hold that lock) so that
On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
> It likes nulls list and we use the pte-list as the nulls which can help us to
> detect whether the "desc" is moved to anther rmap then we can re-walk the rmap
> if that happened
>
> kvm->slots_lock is held when we do lockless walkin
On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
> On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
>> It likes nulls list and we use the pte-list as the nulls which can help us to
>> detect whether the "desc" is moved to anther rmap then we can re-walk the
>> rmap
>> if that
On 11/25/2013 02:11 PM, Xiao Guangrong wrote:
>
> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
>> On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
>>> It likes nulls list and we use the pte-list as the nulls which can help us
>>> to
>>> detect whether the "desc" is moved
On Fri, Nov 22, 2013 at 05:14:29PM -0200, Marcelo Tosatti wrote:
> Also, there is no guarantee of termination (as long as sptes are
> deleted with the correct timing). BTW, can't see any guarantee of
> termination for rculist nulls either (a writer can race with a lockless
> reader indefinately, re
On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
> >
> > For example, nothing prevents lockless walker to move into some
> > parent_ptes chain, right?
>
> No.
>
> The nulls can help us to detect this case, for parent_ptes, the nulls points
> to "shadow page" but for rmaps, the nul
On 11/25/2013 06:19 PM, Gleb Natapov wrote:
> On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
>>>
>>> For example, nothing prevents lockless walker to move into some
>>> parent_ptes chain, right?
>>
>> No.
>>
>> The nulls can help us to detect this case, for parent_ptes, the nulls p
Hi Peter,
On 11/25/2013 05:31 PM, Peter Zijlstra wrote:
> On Fri, Nov 22, 2013 at 05:14:29PM -0200, Marcelo Tosatti wrote:
>> Also, there is no guarantee of termination (as long as sptes are
>> deleted with the correct timing). BTW, can't see any guarantee of
>> termination for rculist nulls eith
On Mon, Nov 25, 2013 at 06:59:24PM +0800, Xiao Guangrong wrote:
>
> Hi Peter,
>
> On 11/25/2013 05:31 PM, Peter Zijlstra wrote:
> > On Fri, Nov 22, 2013 at 05:14:29PM -0200, Marcelo Tosatti wrote:
> >> Also, there is no guarantee of termination (as long as sptes are
> >> deleted with the correct
On Mon, Nov 25, 2013 at 12:05:00PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 25, 2013 at 06:59:24PM +0800, Xiao Guangrong wrote:
> > I guess Marcelo was talking about rculist_nulls.h
> > (Documentation/RCU/rculist_nulls.txt).
>
> Oh, let me have a look, I don't think I've really looked at that ye
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
wrote:
>
> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
I'm not really following, but note that parent_pte predates EPT (and
the use of rcu in kvm), so all the complexity that is the result of
trying to pack as many list entries into a cac
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> wrote:
> >
> > On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
>
>
> I'm not really following, but note that parent_pte predates EPT (and
> the use of rcu in kvm), so all the c
On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
>
> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
> > On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
> >> It likes nulls list and we use the pte-list as the nulls which can help us
> >> to
> >> detect wheth
On Mon, Nov 25, 2013 at 12:23:51PM -0200, Marcelo Tosatti wrote:
> On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> > On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> > wrote:
> > >
> > > On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
> >
> >
> >
> > I'm not really following
GOn Mon, Nov 25, 2013 at 04:29:28PM +0200, Gleb Natapov wrote:
> On Mon, Nov 25, 2013 at 12:23:51PM -0200, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> > > On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> > > wrote:
> > > >
> > > > On Nov 23, 2013, at 3
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> >> Also, there is no guarantee of termination (as long as sptes are
> >> deleted with the correct timing). BTW, can't see any guarantee of
> >> termination for rculist nulls either (a writer can race with a lockless
> >> reader indef
On 11/25/2013 10:08 PM, Marcelo Tosatti wrote:
> On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
>>
>> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>>
>>> On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
It likes nulls list and we use the pte-list as the
On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
>> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
>> wrote:
>>>
>>> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>>
>>
>>
>> I'm not really following, but note that parent_pte pre
On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
Also, there is no guarantee of termination (as long as sptes are
deleted with the correct timing). BTW, can't see any guarantee of
termination for rculist nulls either (a
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> Also, there is no guarantee of termination (as long as sptes are
> deleted with the correct timing). BTW,
On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
> On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> >> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> >> wrote:
> >>>
> >>> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti
On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
> On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> >> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> >> wrote:
> >>>
> >>> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> Also, there is no guarantee of termination (as long as sptes are
> deleted with the correct timing). BTW,
On 11/27/2013 03:58 AM, Marcelo Tosatti wrote:
> On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
>> On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
>>> On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
wrote:
>
On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
> On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
>> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
>>> On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
>> Also, there is no guarantee of termination (as long as sptes
On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
> On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
>> On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
>>> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
>>> Also, the
GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
> On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
> > On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
> >> On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> >>> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> On Mon
On Dec 5, 2013, at 9:50 PM, Marcelo Tosatti wrote:
> GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
>> On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
>>> On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> On
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 rew
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
> 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
On 12/06/2013 08:22 AM, Marcelo Tosatti wrote:
> On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
>> 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：
31 matches
Mail list logo
