On 08/30/2013 07:44 PM, Gleb Natapov wrote:
> On Thu, Aug 29, 2013 at 08:02:30PM +0800, Xiao Guangrong wrote:
>> On 08/29/2013 07:33 PM, Xiao Guangrong wrote:
>>> On 08/29/2013 05:31 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
> After more
On 08/30/2013 07:38 PM, Gleb Natapov wrote:
> On Thu, Aug 29, 2013 at 07:26:40PM +0800, Xiao Guangrong wrote:
>> On 08/29/2013 05:51 PM, Gleb Natapov wrote:
>>> On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
> As Documentation/RCU/whatisRCU.txt says:
>
> As
On 08/30/2013 07:38 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 07:26:40PM +0800, Xiao Guangrong wrote:
On 08/29/2013 05:51 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
As Documentation/RCU/whatisRCU.txt says:
As with
On 08/30/2013 07:44 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 08:02:30PM +0800, Xiao Guangrong wrote:
On 08/29/2013 07:33 PM, Xiao Guangrong wrote:
On 08/29/2013 05:31 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
After more thinking, I still
On Thu, Aug 29, 2013 at 08:02:30PM +0800, Xiao Guangrong wrote:
> On 08/29/2013 07:33 PM, Xiao Guangrong wrote:
> > On 08/29/2013 05:31 PM, Gleb Natapov wrote:
> >> On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
> >>> After more thinking, I still think rcu_assign_pointer() is
On Thu, Aug 29, 2013 at 07:26:40PM +0800, Xiao Guangrong wrote:
> On 08/29/2013 05:51 PM, Gleb Natapov wrote:
> > On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
> >>> As Documentation/RCU/whatisRCU.txt says:
> >>>
> >>> As with rcu_assign_pointer(), an important function
On Thu, Aug 29, 2013 at 07:26:40PM +0800, Xiao Guangrong wrote:
On 08/29/2013 05:51 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
As Documentation/RCU/whatisRCU.txt says:
As with rcu_assign_pointer(), an important function of
On Thu, Aug 29, 2013 at 08:02:30PM +0800, Xiao Guangrong wrote:
On 08/29/2013 07:33 PM, Xiao Guangrong wrote:
On 08/29/2013 05:31 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
After more thinking, I still think rcu_assign_pointer() is unneeded when
On 08/29/2013 07:33 PM, Xiao Guangrong wrote:
> On 08/29/2013 05:31 PM, Gleb Natapov wrote:
>> On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
>>> After more thinking, I still think rcu_assign_pointer() is unneeded when a
>>> entry
>>> is removed. The remove-API does not care the
On 08/29/2013 05:31 PM, Gleb Natapov wrote:
> On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
>> After more thinking, I still think rcu_assign_pointer() is unneeded when a
>> entry
>> is removed. The remove-API does not care the order between unlink the entry
>> and
>> the
On 08/29/2013 05:51 PM, Gleb Natapov wrote:
> On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
>>> As Documentation/RCU/whatisRCU.txt says:
>>>
>>> As with rcu_assign_pointer(), an important function of
>>> rcu_dereference() is to document which pointers are
On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
> > As Documentation/RCU/whatisRCU.txt says:
> >
> > As with rcu_assign_pointer(), an important function of
> > rcu_dereference() is to document which pointers are protected by
> > RCU, in particular, flagging
On 08/29/2013 05:08 PM, Gleb Natapov wrote:
> On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
> BTW I do not see
> rcu_assign_pointer()/rcu_dereference() in your patches which hints on
IIUC, We can not directly use rcu_assign_pointer(), that is something like:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
> After more thinking, I still think rcu_assign_pointer() is unneeded when a
> entry
> is removed. The remove-API does not care the order between unlink the entry
> and
> the changes to its fields. It is the caller's responsibility:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
> >>> BTW I do not see
> >>> rcu_assign_pointer()/rcu_dereference() in your patches which hints on
> >>
> >> IIUC, We can not directly use rcu_assign_pointer(), that is something like:
> >> p = v to assign a pointer to a pointer. But
On 08/28/2013 09:36 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote:
>> On 08/28/2013 06:49 PM, Gleb Natapov wrote:
>>> On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> On Wed, Aug 28,
On 08/28/2013 09:36 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote:
On 08/28/2013 06:49 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
BTW I do not see
rcu_assign_pointer()/rcu_dereference() in your patches which hints on
IIUC, We can not directly use rcu_assign_pointer(), that is something like:
p = v to assign a pointer to a pointer. But in our case, we
On 08/29/2013 05:08 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
BTW I do not see
rcu_assign_pointer()/rcu_dereference() in your patches which hints on
IIUC, We can not directly use rcu_assign_pointer(), that is something like:
p = v to assign a
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
After more thinking, I still think rcu_assign_pointer() is unneeded when a
entry
is removed. The remove-API does not care the order between unlink the entry
and
the changes to its fields. It is the caller's responsibility:
-
On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
As Documentation/RCU/whatisRCU.txt says:
As with rcu_assign_pointer(), an important function of
rcu_dereference() is to document which pointers are protected by
RCU, in particular, flagging a pointer
On 08/29/2013 05:51 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 05:31:42PM +0800, Xiao Guangrong wrote:
As Documentation/RCU/whatisRCU.txt says:
As with rcu_assign_pointer(), an important function of
rcu_dereference() is to document which pointers are protected by
On 08/29/2013 05:31 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
After more thinking, I still think rcu_assign_pointer() is unneeded when a
entry
is removed. The remove-API does not care the order between unlink the entry
and
the changes to its
On 08/29/2013 07:33 PM, Xiao Guangrong wrote:
On 08/29/2013 05:31 PM, Gleb Natapov wrote:
On Thu, Aug 29, 2013 at 02:50:51PM +0800, Xiao Guangrong wrote:
After more thinking, I still think rcu_assign_pointer() is unneeded when a
entry
is removed. The remove-API does not care the order
On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote:
> On 08/28/2013 06:49 PM, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
> >> On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> >>> On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
>
On 08/28/2013 06:49 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
>> On 08/28/2013 05:46 PM, Gleb Natapov wrote:
>>> On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
> Or what if desc is moved to another rmap, but then it
> is
On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
> On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
> >>> Or what if desc is moved to another rmap, but then it
> >>> is moved back to initial rmap (but another place in
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
>>> Or what if desc is moved to another rmap, but then it
>>> is moved back to initial rmap (but another place in the desc list) so
>>> the check here will not catch that we need to
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
> > Or what if desc is moved to another rmap, but then it
> > is moved back to initial rmap (but another place in the desc list) so
> > the check here will not catch that we need to restart walking?
>
> It is okay. We always add the
On 08/28/2013 05:20 PM, Gleb Natapov wrote:
> On Tue, Jul 30, 2013 at 09:02:07PM +0800, Xiao Guangrong wrote:
>> The basic idea is from nulls list which uses a nulls to indicate
>> whether the desc is moved to different pte-list
>>
>> Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
On Tue, Jul 30, 2013 at 09:02:07PM +0800, Xiao Guangrong wrote:
> The basic idea is from nulls list which uses a nulls to indicate
> whether the desc is moved to different pte-list
>
> Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
>
> Signed-off-by: Xiao Guangrong
> ---
>
On Tue, Jul 30, 2013 at 09:02:07PM +0800, Xiao Guangrong wrote:
The basic idea is from nulls list which uses a nulls to indicate
whether the desc is moved to different pte-list
Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
Signed-off-by: Xiao Guangrong
On 08/28/2013 05:20 PM, Gleb Natapov wrote:
On Tue, Jul 30, 2013 at 09:02:07PM +0800, Xiao Guangrong wrote:
The basic idea is from nulls list which uses a nulls to indicate
whether the desc is moved to different pte-list
Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
Or what if desc is moved to another rmap, but then it
is moved back to initial rmap (but another place in the desc list) so
the check here will not catch that we need to restart walking?
It is okay. We always add the new desc
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
Or what if desc is moved to another rmap, but then it
is moved back to initial rmap (but another place in the desc list) so
the check here will not catch that we need to restart walking?
On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
Or what if desc is moved to another rmap, but then it
is moved back to initial rmap (but another place in the desc
On 08/28/2013 06:49 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
Or what if desc is moved to another rmap, but then it
is moved back to
On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote:
On 08/28/2013 06:49 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
Or what
The basic idea is from nulls list which uses a nulls to indicate
whether the desc is moved to different pte-list
Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 51 ++-
1 file
The basic idea is from nulls list which uses a nulls to indicate
whether the desc is moved to different pte-list
Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 51
40 matches
Mail list logo
