On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
> On 29/09/2017 11:30, Boqun Feng wrote:
> > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
> > [...]
> >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292
> >>> schedule+0x113/0x460 kernel/sched/core.c:3421
> >>>
On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
> On 29/09/2017 11:30, Boqun Feng wrote:
> > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
> > [...]
> >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292
> >>> schedule+0x113/0x460 kernel/sched/core.c:3421
> >>>
On Fri, Sep 29, 2017 at 01:44:56PM +0200, Paolo Bonzini wrote:
> On 29/09/2017 12:34, Peter Zijlstra wrote:
> > On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
> >>> Does this mean whenever we get a page fault in a RCU read-side critical
> >>> section, we may hit this?
> >>>
> >>>
On Fri, Sep 29, 2017 at 01:44:56PM +0200, Paolo Bonzini wrote:
> On 29/09/2017 12:34, Peter Zijlstra wrote:
> > On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
> >>> Does this mean whenever we get a page fault in a RCU read-side critical
> >>> section, we may hit this?
> >>>
> >>>
On 29/09/2017 12:34, Peter Zijlstra wrote:
> On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
>>> Does this mean whenever we get a page fault in a RCU read-side critical
>>> section, we may hit this?
>>>
>>> Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the
>>>
On 29/09/2017 12:34, Peter Zijlstra wrote:
> On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
>>> Does this mean whenever we get a page fault in a RCU read-side critical
>>> section, we may hit this?
>>>
>>> Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the
>>>
On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
> > Does this mean whenever we get a page fault in a RCU read-side critical
> > section, we may hit this?
> >
> > Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the
> > fault process is in a RCU read-side critical
On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote:
> > Does this mean whenever we get a page fault in a RCU read-side critical
> > section, we may hit this?
> >
> > Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the
> > fault process is in a RCU read-side critical
On Fri, Sep 29, 2017 at 10:01:24AM +, Paolo Bonzini wrote:
> On 29/09/2017 11:30, Boqun Feng wrote:
> > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
> > [...]
> >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292
> >>> schedule+0x113/0x460 kernel/sched/core.c:3421
> >>>
On Fri, Sep 29, 2017 at 10:01:24AM +, Paolo Bonzini wrote:
> On 29/09/2017 11:30, Boqun Feng wrote:
> > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
> > [...]
> >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292
> >>> schedule+0x113/0x460 kernel/sched/core.c:3421
> >>>
On 29/09/2017 11:30, Boqun Feng wrote:
> On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
> [...]
>>> __schedule+0x201/0x2240 kernel/sched/core.c:3292
>>> schedule+0x113/0x460 kernel/sched/core.c:3421
>>> kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
>>
>> It is
On 29/09/2017 11:30, Boqun Feng wrote:
> On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
> [...]
>>> __schedule+0x201/0x2240 kernel/sched/core.c:3292
>>> schedule+0x113/0x460 kernel/sched/core.c:3421
>>> kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
>>
>> It is
On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
[...]
> > __schedule+0x201/0x2240 kernel/sched/core.c:3292
> > schedule+0x113/0x460 kernel/sched/core.c:3421
> > kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
>
> It is kvm_async_pf_task_wait() that calls
On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote:
[...]
> > __schedule+0x201/0x2240 kernel/sched/core.c:3292
> > schedule+0x113/0x460 kernel/sched/core.c:3421
> > kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
>
> It is kvm_async_pf_task_wait() that calls
On Thu, Sep 28, 2017 at 06:18:50PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 28, 2017 at 09:05:14AM -0700, Paul E. McKenney wrote:
> > > do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
> > > async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
> > > RIP:
On Thu, Sep 28, 2017 at 06:18:50PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 28, 2017 at 09:05:14AM -0700, Paul E. McKenney wrote:
> > > do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
> > > async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
> > > RIP:
On Thu, Sep 28, 2017 at 06:08:56PM +0200, Peter Zijlstra wrote:
>On Thu, Sep 28, 2017 at 03:38:16PM +, Levin, Alexander (Sasha Levin) wrote:
>> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
>
>> >Hmmm... kernel/rcu/tree_plugin.h:329 thinks that someone slept (as opposed
>>
On Thu, Sep 28, 2017 at 06:08:56PM +0200, Peter Zijlstra wrote:
>On Thu, Sep 28, 2017 at 03:38:16PM +, Levin, Alexander (Sasha Levin) wrote:
>> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
>
>> >Hmmm... kernel/rcu/tree_plugin.h:329 thinks that someone slept (as opposed
>>
On Thu, Sep 28, 2017 at 09:05:14AM -0700, Paul E. McKenney wrote:
> > do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
> > async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
> > RIP: 0010:format_decode+0x240/0x830 lib/vsprintf.c:1996
> > RSP: 0018:88003b2df520 EFLAGS: 00010283
On Thu, Sep 28, 2017 at 09:05:14AM -0700, Paul E. McKenney wrote:
> > do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
> > async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
> > RIP: 0010:format_decode+0x240/0x830 lib/vsprintf.c:1996
> > RSP: 0018:88003b2df520 EFLAGS: 00010283
On Thu, Sep 28, 2017 at 03:38:16PM +, Levin, Alexander (Sasha Levin) wrote:
> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
> >Hmmm... kernel/rcu/tree_plugin.h:329 thinks that someone slept (as opposed
> >to was preempted) in an RCU read-side critical section.
Sasha, was
On Thu, Sep 28, 2017 at 03:38:16PM +, Levin, Alexander (Sasha Levin) wrote:
> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
> >Hmmm... kernel/rcu/tree_plugin.h:329 thinks that someone slept (as opposed
> >to was preempted) in an RCU read-side critical section.
Sasha, was
On Thu, Sep 28, 2017 at 03:38:16PM +, Levin, Alexander (Sasha Levin) wrote:
> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
> >On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote:
> >> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
> >>
On Thu, Sep 28, 2017 at 03:38:16PM +, Levin, Alexander (Sasha Levin) wrote:
> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
> >On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote:
> >> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
> >> wrote:
> >> > Currently,
On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
>On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote:
>> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
>> wrote:
>> > Currently, a call to schedule() acts as a Tasks RCU quiescent state
>> >
On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote:
>On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote:
>> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
>> wrote:
>> > Currently, a call to schedule() acts as a Tasks RCU quiescent state
>> > only if a context switch
On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote:
> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
> wrote:
> > Currently, a call to schedule() acts as a Tasks RCU quiescent state
> > only if a context switch actually takes place. However, just the
> >
On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote:
> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
> wrote:
> > Currently, a call to schedule() acts as a Tasks RCU quiescent state
> > only if a context switch actually takes place. However, just the
> > call to schedule() guarantees
On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
wrote:
> Currently, a call to schedule() acts as a Tasks RCU quiescent state
> only if a context switch actually takes place. However, just the
> call to schedule() guarantees that the calling task has moved off of
>
On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney
wrote:
> Currently, a call to schedule() acts as a Tasks RCU quiescent state
> only if a context switch actually takes place. However, just the
> call to schedule() guarantees that the calling task has moved off of
> whatever tracing trampoline
Currently, a call to schedule() acts as a Tasks RCU quiescent state
only if a context switch actually takes place. However, just the
call to schedule() guarantees that the calling task has moved off of
whatever tracing trampoline that it might have been one previously.
This commit therefore
Currently, a call to schedule() acts as a Tasks RCU quiescent state
only if a context switch actually takes place. However, just the
call to schedule() guarantees that the calling task has moved off of
whatever tracing trampoline that it might have been one previously.
This commit therefore
32 matches
Mail list logo