On Sun, 2012-01-29 at 10:25 +0200, Gilad Ben-Yossef wrote:
>
> If this is of interest, I keep a list tracking global IPI and global
> task schedulers sources in the core kernel here:
> https://github.com/gby/linux/wiki.
You can add synchronize_.*_expedited() to the list, it does its best to
bash the entire machine in order to try and make RCU grace periods
happen fast.
On Wed, 2012-02-01 at 18:35 +0100, Peter Zijlstra wrote:
> On Sun, 2012-01-29 at 10:25 +0200, Gilad Ben-Yossef wrote:
> >
> > If this is of interest, I keep a list tracking global IPI and global
> > task schedulers sources in the core kernel here:
> > https://github.com/gby/linux/wiki.
>
> You can add synchronize_.*_expedited() to the list, it does its best to
> bash the entire machine in order to try and make RCU grace periods
> happen fast.
Also anything using stop_machine, such as module unload, cpu hot-unplug
and text_poke().
On Wed, Feb 01, 2012 at 06:35:22PM +0100, Peter Zijlstra wrote:
> On Sun, 2012-01-29 at 10:25 +0200, Gilad Ben-Yossef wrote:
> >
> > If this is of interest, I keep a list tracking global IPI and global
> > task schedulers sources in the core kernel here:
> > https://github.com/gby/linux/wiki.
>
> You can add synchronize_.*_expedited() to the list, it does its best to
> bash the entire machine in order to try and make RCU grace periods
> happen fast.
I have duly added "Make synchronize_sched_expedited() avoid IPIing idle
CPUs" to http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html.
This should not be hard once I have built up some trust in the new
RCU idle-detection code. It would also automatically apply to
Frederic's dyntick-idle userspace work.
Thanx, Paul
On Wed, 1 Feb 2012, Paul E. McKenney wrote:
> On Wed, Feb 01, 2012 at 06:35:22PM +0100, Peter Zijlstra wrote:
> > On Sun, 2012-01-29 at 10:25 +0200, Gilad Ben-Yossef wrote:
> > >
> > > If this is of interest, I keep a list tracking global IPI and global
> > > task schedulers sources in the core kernel here:
> > > https://github.com/gby/linux/wiki.
> >
> > You can add synchronize_.*_expedited() to the list, it does its best to
> > bash the entire machine in order to try and make RCU grace periods
> > happen fast.
>
> I have duly added "Make synchronize_sched_expedited() avoid IPIing idle
> CPUs" to http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html.
>
> This should not be hard once I have built up some trust in the new
> RCU idle-detection code. It would also automatically apply to
> Frederic's dyntick-idle userspace work.
Could we also apply the same approach to processors busy doing
computational work? In that case the OS is also not needed. Interrupting
these activities is impacting on performance and latency.
On Wed, Feb 01, 2012 at 02:06:07PM -0600, Christoph Lameter wrote:
> On Wed, 1 Feb 2012, Paul E. McKenney wrote:
>
> > On Wed, Feb 01, 2012 at 06:35:22PM +0100, Peter Zijlstra wrote:
> > > On Sun, 2012-01-29 at 10:25 +0200, Gilad Ben-Yossef wrote:
> > > >
> > > > If this is of interest, I keep a list tracking global IPI and global
> > > > task schedulers sources in the core kernel here:
> > > > https://github.com/gby/linux/wiki.
> > >
> > > You can add synchronize_.*_expedited() to the list, it does its best to
> > > bash the entire machine in order to try and make RCU grace periods
> > > happen fast.
> >
> > I have duly added "Make synchronize_sched_expedited() avoid IPIing idle
> > CPUs" to http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html.
> >
> > This should not be hard once I have built up some trust in the new
> > RCU idle-detection code. It would also automatically apply to
> > Frederic's dyntick-idle userspace work.
>
> Could we also apply the same approach to processors busy doing
> computational work? In that case the OS is also not needed. Interrupting
> these activities is impacting on performance and latency.
Yep, that is in fact what Frederic's dyntick-idle userspace work does.
Thanx, Paul
On 02/01/2012 10:13 PM, Paul E. McKenney wrote:
> >
> > Could we also apply the same approach to processors busy doing
> > computational work? In that case the OS is also not needed. Interrupting
> > these activities is impacting on performance and latency.
>
> Yep, that is in fact what Frederic's dyntick-idle userspace work does.
>
Running in a guest is a special case of running in userspace, so we'd
need to extend this work to kvm as well.
--
error compiling committee.c: too many arguments to function
On Wed, Feb 1, 2012 at 7:57 PM, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2012-02-01 at 18:35 +0100, Peter Zijlstra wrote:
>> On Sun, 2012-01-29 at 10:25 +0200, Gilad Ben-Yossef wrote:
>> >
>> > If this is of interest, I keep a list tracking global IPI and global
>> > task schedulers sources in the core kernel here:
>> > https://github.com/gby/linux/wiki.
>>
>> You can add synchronize_.*_expedited() to the list, it does its best to
>> bash the entire machine in order to try and make RCU grace periods
>> happen fast.
>
> Also anything using stop_machine, such as module unload, cpu hot-unplug
> and text_poke().
Thanks! I've added it to the list together with the clocksource
watchdog, which is registering
a timer on each cpu in a cyclinc fashion.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
?-- Jean-Baptiste Queru
On Thu, Feb 02, 2012 at 11:34:25AM +0200, Avi Kivity wrote:
> On 02/01/2012 10:13 PM, Paul E. McKenney wrote:
> > >
> > > Could we also apply the same approach to processors busy doing
> > > computational work? In that case the OS is also not needed. Interrupting
> > > these activities is impacting on performance and latency.
> >
> > Yep, that is in fact what Frederic's dyntick-idle userspace work does.
>
> Running in a guest is a special case of running in userspace, so we'd
> need to extend this work to kvm as well.
As long as rcu_idle_enter() is called at the appropriate time, RCU will
happily ignore the CPU. ;-)
Thanx, Paul
On 02/02/2012 05:34 PM, Paul E. McKenney wrote:
> On Thu, Feb 02, 2012 at 11:34:25AM +0200, Avi Kivity wrote:
> > On 02/01/2012 10:13 PM, Paul E. McKenney wrote:
> > > >
> > > > Could we also apply the same approach to processors busy doing
> > > > computational work? In that case the OS is also not needed. Interrupting
> > > > these activities is impacting on performance and latency.
> > >
> > > Yep, that is in fact what Frederic's dyntick-idle userspace work does.
> >
> > Running in a guest is a special case of running in userspace, so we'd
> > need to extend this work to kvm as well.
>
> As long as rcu_idle_enter() is called at the appropriate time, RCU will
> happily ignore the CPU. ;-)
>
It's not called (since the cpu is not idle). Instead we call
rcu_virt_note_context_switch().
--
error compiling committee.c: too many arguments to function
On Thu, Feb 02, 2012 at 06:14:36PM +0200, Avi Kivity wrote:
> On 02/02/2012 05:34 PM, Paul E. McKenney wrote:
> > On Thu, Feb 02, 2012 at 11:34:25AM +0200, Avi Kivity wrote:
> > > On 02/01/2012 10:13 PM, Paul E. McKenney wrote:
> > > > >
> > > > > Could we also apply the same approach to processors busy doing
> > > > > computational work? In that case the OS is also not needed. Interrupting
> > > > > these activities is impacting on performance and latency.
> > > >
> > > > Yep, that is in fact what Frederic's dyntick-idle userspace work does.
> > >
> > > Running in a guest is a special case of running in userspace, so we'd
> > > need to extend this work to kvm as well.
> >
> > As long as rcu_idle_enter() is called at the appropriate time, RCU will
> > happily ignore the CPU. ;-)
> >
>
> It's not called (since the cpu is not idle). Instead we call
> rcu_virt_note_context_switch().
Frederic's work checks to see if there is only one runnable user task
on a given CPU. If there is only one, then the scheduling-clock interrupt
is turned off for that CPU, and RCU is told to ignore it while it is
executing in user space. Not sure whether this covers KVM guests.
In any case, this is not yet in mainline.
Thanx, Paul
On 02/02/2012 07:01 PM, Paul E. McKenney wrote:
> >
> > It's not called (since the cpu is not idle). Instead we call
> > rcu_virt_note_context_switch().
>
> Frederic's work checks to see if there is only one runnable user task
> on a given CPU. If there is only one, then the scheduling-clock interrupt
> is turned off for that CPU, and RCU is told to ignore it while it is
> executing in user space. Not sure whether this covers KVM guests.
Conceptually it's the same. Maybe it needs adjustments, since kvm
enters a guest in a different way than the kernel exits to userspace.
> In any case, this is not yet in mainline.
Let me know when it's in, and I'll have a look.
--
error compiling committee.c: too many arguments to function
On Thu, 2 Feb 2012, Paul E. McKenney wrote:
> Frederic's work checks to see if there is only one runnable user task
> on a given CPU. If there is only one, then the scheduling-clock interrupt
> is turned off for that CPU, and RCU is told to ignore it while it is
> executing in user space. Not sure whether this covers KVM guests.
>
> In any case, this is not yet in mainline.
Sounds great. Is there any plan on when to merge it? Where are the most up
to date patches vs mainstream?
On Thu, Feb 02, 2012 at 07:23:39PM +0200, Avi Kivity wrote:
> On 02/02/2012 07:01 PM, Paul E. McKenney wrote:
> > >
> > > It's not called (since the cpu is not idle). Instead we call
> > > rcu_virt_note_context_switch().
> >
> > Frederic's work checks to see if there is only one runnable user task
> > on a given CPU. If there is only one, then the scheduling-clock interrupt
> > is turned off for that CPU, and RCU is told to ignore it while it is
> > executing in user space. Not sure whether this covers KVM guests.
>
> Conceptually it's the same. Maybe it needs adjustments, since kvm
> enters a guest in a different way than the kernel exits to userspace.
>
> > In any case, this is not yet in mainline.
>
> Let me know when it's in, and I'll have a look.
Could you please touch base with Frederic Weisbecker to make sure that
what he is doing works for you?
Thanx, Paul
On Thu, Feb 2, 2012 at 7:25 PM, Christoph Lameter <[email protected]> wrote:
> On Thu, 2 Feb 2012, Paul E. McKenney wrote:
>
>> Frederic's work checks to see if there is only one runnable user task
>> on a given CPU. ?If there is only one, then the scheduling-clock interrupt
>> is turned off for that CPU, and RCU is told to ignore it while it is
>> executing in user space. ?Not sure whether this covers KVM guests.
>>
>> In any case, this is not yet in mainline.
>
> Sounds great. Is there any plan on when to merge it? Where are the most up
> to date patches vs mainstream?
>
Frederic has the latest version in a git tree here:
git://github.com/fweisbec/linux-dynticks.git
nohz/cpuset-v2-pre-20120117
It's on top latest rcu/core.
I've been playing with it for some time now. It works very well, considering the
early state - there are a couple of TODO items listed here:
https://tglx.de/~fweisbec/TODO-nohz-cpusets and I've seen an assert from
the RCU code once.
Also, there is some system stuff "in the way" so to speak, of getting the full
benefits:
I had to disable the clock source watchdog (I'm testing in a KVM VM, so I guess
the TSC is not stable), the vmstat_stats work on that CPU and to (try
to) fix what
looks like a bug in the NOHZ timer code.
But the good news is that with these hacks applied I managed to run a 100%
CPU task with zero interrupts (ticks or otherwise) on an isolated cpu.
Disregarding TLB overhead, you get bare metal performance with Linux user
space manageability and debug capabilities. Pretty magical really: It's like
eating your cake and having it too :-)
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
http://benyossef.com
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
?-- Jean-Baptiste Queru
On 02/02/2012 07:51 PM, Paul E. McKenney wrote:
> On Thu, Feb 02, 2012 at 07:23:39PM +0200, Avi Kivity wrote:
> > On 02/02/2012 07:01 PM, Paul E. McKenney wrote:
> > > >
> > > > It's not called (since the cpu is not idle). Instead we call
> > > > rcu_virt_note_context_switch().
> > >
> > > Frederic's work checks to see if there is only one runnable user task
> > > on a given CPU. If there is only one, then the scheduling-clock interrupt
> > > is turned off for that CPU, and RCU is told to ignore it while it is
> > > executing in user space. Not sure whether this covers KVM guests.
> >
> > Conceptually it's the same. Maybe it needs adjustments, since kvm
> > enters a guest in a different way than the kernel exits to userspace.
> >
> > > In any case, this is not yet in mainline.
> >
> > Let me know when it's in, and I'll have a look.
>
> Could you please touch base with Frederic Weisbecker to make sure that
> what he is doing works for you?
>
Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
only need one set of APIs.
--
error compiling committee.c: too many arguments to function
On Sun, Feb 05, 2012 at 02:16:17PM +0200, Avi Kivity wrote:
> On 02/02/2012 07:51 PM, Paul E. McKenney wrote:
> > On Thu, Feb 02, 2012 at 07:23:39PM +0200, Avi Kivity wrote:
> > > On 02/02/2012 07:01 PM, Paul E. McKenney wrote:
> > > > >
> > > > > It's not called (since the cpu is not idle). Instead we call
> > > > > rcu_virt_note_context_switch().
> > > >
> > > > Frederic's work checks to see if there is only one runnable user task
> > > > on a given CPU. If there is only one, then the scheduling-clock interrupt
> > > > is turned off for that CPU, and RCU is told to ignore it while it is
> > > > executing in user space. Not sure whether this covers KVM guests.
> > >
> > > Conceptually it's the same. Maybe it needs adjustments, since kvm
> > > enters a guest in a different way than the kernel exits to userspace.
> > >
> > > > In any case, this is not yet in mainline.
> > >
> > > Let me know when it's in, and I'll have a look.
> >
> > Could you please touch base with Frederic Weisbecker to make sure that
> > what he is doing works for you?
>
> Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
> only need one set of APIs.
Now that you mention it, that is a good goal. However, it requires
coordination with Frederic's code as well, so some investigation
is required. Bad things happen if you tell RCU you are idle when you
really are not and vice versa!
Thanx, Paul
On Sun, 5 Feb 2012, Gilad Ben-Yossef wrote
>
> Frederic has the latest version in a git tree here:
>
> git://github.com/fweisbec/linux-dynticks.git
> nohz/cpuset-v2-pre-20120117
>
> It's on top latest rcu/core.
Hmmm.. A pull vs upstream leads to lots of conflicts.
> But the good news is that with these hacks applied I managed to run a 100%
> CPU task with zero interrupts (ticks or otherwise) on an isolated cpu.
Cool.
> Disregarding TLB overhead, you get bare metal performance with Linux user
> space manageability and debug capabilities. Pretty magical really: It's like
> eating your cake and having it too :-)
We definitely need that.
On Sun, Feb 05, 2012 at 08:59:27AM -0800, Paul E. McKenney wrote:
> On Sun, Feb 05, 2012 at 02:16:17PM +0200, Avi Kivity wrote:
> > On 02/02/2012 07:51 PM, Paul E. McKenney wrote:
> > > On Thu, Feb 02, 2012 at 07:23:39PM +0200, Avi Kivity wrote:
> > > > On 02/02/2012 07:01 PM, Paul E. McKenney wrote:
> > > > > >
> > > > > > It's not called (since the cpu is not idle). Instead we call
> > > > > > rcu_virt_note_context_switch().
> > > > >
> > > > > Frederic's work checks to see if there is only one runnable user task
> > > > > on a given CPU. If there is only one, then the scheduling-clock interrupt
> > > > > is turned off for that CPU, and RCU is told to ignore it while it is
> > > > > executing in user space. Not sure whether this covers KVM guests.
> > > >
> > > > Conceptually it's the same. Maybe it needs adjustments, since kvm
> > > > enters a guest in a different way than the kernel exits to userspace.
> > > >
> > > > > In any case, this is not yet in mainline.
> > > >
> > > > Let me know when it's in, and I'll have a look.
> > >
> > > Could you please touch base with Frederic Weisbecker to make sure that
> > > what he is doing works for you?
> >
> > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> > we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
> > only need one set of APIs.
>
> Now that you mention it, that is a good goal. However, it requires
> coordination with Frederic's code as well, so some investigation
> is required. Bad things happen if you tell RCU you are idle when you
> really are not and vice versa!
>
> Thanx, Paul
>
Right. Avi I need to know more about what you need. rcu_virt_note_context_switch()
notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same
thing than rcu_idle_enter() minus the is_idle_cpu() checks).
On Mon, Feb 06, 2012 at 12:19:44PM -0600, Christoph Lameter wrote:
> On Sun, 5 Feb 2012, Gilad Ben-Yossef wrote
>
> >
> > Frederic has the latest version in a git tree here:
> >
> > git://github.com/fweisbec/linux-dynticks.git
> > nohz/cpuset-v2-pre-20120117
> >
> > It's on top latest rcu/core.
>
> Hmmm.. A pull vs upstream leads to lots of conflicts.
Yeah it's based on the latest rcu/core branch that was pulled
on last -rc1. Better git checkout it than pull.
>
> > But the good news is that with these hacks applied I managed to run a 100%
> > CPU task with zero interrupts (ticks or otherwise) on an isolated cpu.
>
> Cool.
>
> > Disregarding TLB overhead, you get bare metal performance with Linux user
> > space manageability and debug capabilities. Pretty magical really: It's like
> > eating your cake and having it too :-)
>
> We definitely need that.
>
On 02/09/2012 05:22 PM, Frederic Weisbecker wrote:
> > >
> > > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> > > we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
> > > only need one set of APIs.
> >
> > Now that you mention it, that is a good goal. However, it requires
> > coordination with Frederic's code as well, so some investigation
> > is required. Bad things happen if you tell RCU you are idle when you
> > really are not and vice versa!
> >
> > Thanx, Paul
> >
>
> Right. Avi I need to know more about what you need. rcu_virt_note_context_switch()
> notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same
> thing than rcu_idle_enter() minus the is_idle_cpu() checks).
I don't know enough about RCU to say if it's okay or not (I typically
peek at the quick quiz answers). However, switching to guest mode is
very similar to exiting to user mode: we're guaranteed not to be in an
rcu critical section, and to remain so until the guest exits back to
us. What guarantees does rcu_user_enter() provide? With luck guest
entry satisifies them all.
--
error compiling committee.c: too many arguments to function
On Thu, Feb 09, 2012 at 06:05:07PM +0200, Avi Kivity wrote:
> On 02/09/2012 05:22 PM, Frederic Weisbecker wrote:
> > > >
> > > > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> > > > we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
> > > > only need one set of APIs.
> > >
> > > Now that you mention it, that is a good goal. However, it requires
> > > coordination with Frederic's code as well, so some investigation
> > > is required. Bad things happen if you tell RCU you are idle when you
> > > really are not and vice versa!
> > >
> > > Thanx, Paul
> > >
> >
> > Right. Avi I need to know more about what you need. rcu_virt_note_context_switch()
> > notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same
> > thing than rcu_idle_enter() minus the is_idle_cpu() checks).
>
> I don't know enough about RCU to say if it's okay or not (I typically
> peek at the quick quiz answers). However, switching to guest mode is
> very similar to exiting to user mode: we're guaranteed not to be in an
> rcu critical section, and to remain so until the guest exits back to
> us.
Awesome!
> What guarantees does rcu_user_enter() provide? With luck guest
> entry satisifies them all.
So rcu_user_enter() puts the CPU into RCU idle mode, which means the CPU
won't need to be part of the global RCU grace period completion. This
prevents it to depend on the timer tick (although for now you keep it)
and to complete some RCU specific work during the tick.
Paul, do you think that would be a win?
On Thu, Feb 09, 2012 at 07:22:19PM +0100, Frederic Weisbecker wrote:
> On Thu, Feb 09, 2012 at 06:05:07PM +0200, Avi Kivity wrote:
> > On 02/09/2012 05:22 PM, Frederic Weisbecker wrote:
> > > > >
> > > > > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> > > > > we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
> > > > > only need one set of APIs.
> > > >
> > > > Now that you mention it, that is a good goal. However, it requires
> > > > coordination with Frederic's code as well, so some investigation
> > > > is required. Bad things happen if you tell RCU you are idle when you
> > > > really are not and vice versa!
> > > >
> > > > Thanx, Paul
> > > >
> > >
> > > Right. Avi I need to know more about what you need. rcu_virt_note_context_switch()
> > > notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same
> > > thing than rcu_idle_enter() minus the is_idle_cpu() checks).
> >
> > I don't know enough about RCU to say if it's okay or not (I typically
> > peek at the quick quiz answers). However, switching to guest mode is
> > very similar to exiting to user mode: we're guaranteed not to be in an
> > rcu critical section, and to remain so until the guest exits back to
> > us.
>
> Awesome!
>
> > What guarantees does rcu_user_enter() provide? With luck guest
> > entry satisifies them all.
>
> So rcu_user_enter() puts the CPU into RCU idle mode, which means the CPU
> won't need to be part of the global RCU grace period completion. This
> prevents it to depend on the timer tick (although for now you keep it)
> and to complete some RCU specific work during the tick.
>
> Paul, do you think that would be a win?
As long as the code doesn't enter RCU read-side critical sections in
the time between rcu_idle_enter() and rcu_idle_exit(), this should
work fine.
Thanx, Paul
On Thu, Feb 09, 2012 at 03:41:45PM -0800, Paul E. McKenney wrote:
> On Thu, Feb 09, 2012 at 07:22:19PM +0100, Frederic Weisbecker wrote:
> > On Thu, Feb 09, 2012 at 06:05:07PM +0200, Avi Kivity wrote:
> > > On 02/09/2012 05:22 PM, Frederic Weisbecker wrote:
> > > > > >
> > > > > > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> > > > > > we can use. Hopefully they subsume rcu_virt_note_context_switch() so we
> > > > > > only need one set of APIs.
> > > > >
> > > > > Now that you mention it, that is a good goal. However, it requires
> > > > > coordination with Frederic's code as well, so some investigation
> > > > > is required. Bad things happen if you tell RCU you are idle when you
> > > > > really are not and vice versa!
> > > > >
> > > > > Thanx, Paul
> > > > >
> > > >
> > > > Right. Avi I need to know more about what you need. rcu_virt_note_context_switch()
> > > > notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same
> > > > thing than rcu_idle_enter() minus the is_idle_cpu() checks).
> > >
> > > I don't know enough about RCU to say if it's okay or not (I typically
> > > peek at the quick quiz answers). However, switching to guest mode is
> > > very similar to exiting to user mode: we're guaranteed not to be in an
> > > rcu critical section, and to remain so until the guest exits back to
> > > us.
> >
> > Awesome!
> >
> > > What guarantees does rcu_user_enter() provide? With luck guest
> > > entry satisifies them all.
> >
> > So rcu_user_enter() puts the CPU into RCU idle mode, which means the CPU
> > won't need to be part of the global RCU grace period completion. This
> > prevents it to depend on the timer tick (although for now you keep it)
> > and to complete some RCU specific work during the tick.
> >
> > Paul, do you think that would be a win?
>
> As long as the code doesn't enter RCU read-side critical sections in
> the time between rcu_idle_enter() and rcu_idle_exit(), this should
> work fine.
This should work fine yeah but further the correctness, I wonder if this
is going to be a win.
We use rcu_idle_enter() in idle to avoid to keep the tick for RCU. But
what about falling into guest mode? I guess the tick is kept there
so is it going to be a win in throughput or something to use rcu_idle_enter()?
On 02/10/2012 03:39 AM, Frederic Weisbecker wrote:
> >
> > As long as the code doesn't enter RCU read-side critical sections in
> > the time between rcu_idle_enter() and rcu_idle_exit(), this should
> > work fine.
>
> This should work fine yeah but further the correctness, I wonder if this
> is going to be a win.
>
> We use rcu_idle_enter() in idle to avoid to keep the tick for RCU. But
> what about falling into guest mode? I guess the tick is kept there
> so is it going to be a win in throughput or something to use rcu_idle_enter()?
We could disable the tick while in guest mode as well. Interrupts in
guest mode are even more expensive than interrupts in user mode.
--
error compiling committee.c: too many arguments to function
On Tue, Feb 14, 2012 at 03:18:03PM +0200, Avi Kivity wrote:
> On 02/10/2012 03:39 AM, Frederic Weisbecker wrote:
> > >
> > > As long as the code doesn't enter RCU read-side critical sections in
> > > the time between rcu_idle_enter() and rcu_idle_exit(), this should
> > > work fine.
> >
> > This should work fine yeah but further the correctness, I wonder if this
> > is going to be a win.
> >
> > We use rcu_idle_enter() in idle to avoid to keep the tick for RCU. But
> > what about falling into guest mode? I guess the tick is kept there
> > so is it going to be a win in throughput or something to use rcu_idle_enter()?
>
> We could disable the tick while in guest mode as well. Interrupts in
> guest mode are even more expensive than interrupts in user mode.
Right, that's definitely something I need to explore with the adaptive tickless
thing.