On Wed, Sep 12, 2012 at 02:41:36PM +0200, Peter Zijlstra wrote:
> On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote:
> >
> > 1) This can happen if something calls set_need_resched() while no other
> > task is
> > on the runqueue.
>
> People really shouldn't be doing that... I think I
On Wed, 2012-09-12 at 15:54 +0200, Frederic Weisbecker wrote:
> On Wed, Sep 12, 2012 at 02:52:40PM +0200, Peter Zijlstra wrote:
> > On Wed, 2012-09-12 at 14:41 +0200, Peter Zijlstra wrote:
> >
> > > We could of course mandate that all remote wakeups to special nohz cpus
> > > get queued. That
On Wed, Sep 12, 2012 at 02:52:40PM +0200, Peter Zijlstra wrote:
> On Wed, 2012-09-12 at 14:41 +0200, Peter Zijlstra wrote:
>
> > We could of course mandate that all remote wakeups to special nohz cpus
> > get queued. That would just leave us with RCU and it would simply not
> > send resched IPIs
On Wed, Sep 12, 2012 at 02:41:36PM +0200, Peter Zijlstra wrote:
> On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote:
> >
> > 1) This can happen if something calls set_need_resched() while no other
> > task is
> > on the runqueue.
>
> People really shouldn't be doing that... I think I
On Wed, 2012-09-12 at 14:41 +0200, Peter Zijlstra wrote:
> We could of course mandate that all remote wakeups to special nohz cpus
> get queued. That would just leave us with RCU and it would simply not
> send resched IPIs to extended quiescent CPUs anyway, right?
>
> So at that point all return
On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote:
>
> 1) This can happen if something calls set_need_resched() while no other task
> is
> on the runqueue.
People really shouldn't be doing that... I think I know why RCU does
this, but yuck. I also think RCU can avoid doing this, but
On Wed, Sep 12, 2012 at 11:33:33AM +0200, Peter Zijlstra wrote:
> On Mon, 2012-09-10 at 22:26 +0200, Frederic Weisbecker wrote:
>
> > > > OK, so colour me unconvinced.. why are we doing this?
> > > >
> > > > Typically when we call schedule nr_running != 1 (we need current to be
> > > > running
On Mon, 2012-09-10 at 22:26 +0200, Frederic Weisbecker wrote:
> > > OK, so colour me unconvinced.. why are we doing this?
> > >
> > > Typically when we call schedule nr_running != 1 (we need current to be
> > > running and a possible target to switch to).
> > >
> > > So I'd prefer to simply
On Mon, 2012-09-10 at 22:26 +0200, Frederic Weisbecker wrote:
OK, so colour me unconvinced.. why are we doing this?
Typically when we call schedule nr_running != 1 (we need current to be
running and a possible target to switch to).
So I'd prefer to simply have schedule()
On Wed, Sep 12, 2012 at 11:33:33AM +0200, Peter Zijlstra wrote:
On Mon, 2012-09-10 at 22:26 +0200, Frederic Weisbecker wrote:
OK, so colour me unconvinced.. why are we doing this?
Typically when we call schedule nr_running != 1 (we need current to be
running and a possible
On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote:
1) This can happen if something calls set_need_resched() while no other task
is
on the runqueue.
People really shouldn't be doing that... I think I know why RCU does
this, but yuck. I also think RCU can avoid doing this, but its
On Wed, 2012-09-12 at 14:41 +0200, Peter Zijlstra wrote:
We could of course mandate that all remote wakeups to special nohz cpus
get queued. That would just leave us with RCU and it would simply not
send resched IPIs to extended quiescent CPUs anyway, right?
So at that point all return to
On Wed, Sep 12, 2012 at 02:41:36PM +0200, Peter Zijlstra wrote:
On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote:
1) This can happen if something calls set_need_resched() while no other
task is
on the runqueue.
People really shouldn't be doing that... I think I know why
On Wed, Sep 12, 2012 at 02:52:40PM +0200, Peter Zijlstra wrote:
On Wed, 2012-09-12 at 14:41 +0200, Peter Zijlstra wrote:
We could of course mandate that all remote wakeups to special nohz cpus
get queued. That would just leave us with RCU and it would simply not
send resched IPIs to
On Wed, 2012-09-12 at 15:54 +0200, Frederic Weisbecker wrote:
On Wed, Sep 12, 2012 at 02:52:40PM +0200, Peter Zijlstra wrote:
On Wed, 2012-09-12 at 14:41 +0200, Peter Zijlstra wrote:
We could of course mandate that all remote wakeups to special nohz cpus
get queued. That would just
On Wed, Sep 12, 2012 at 02:41:36PM +0200, Peter Zijlstra wrote:
On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote:
1) This can happen if something calls set_need_resched() while no other
task is
on the runqueue.
People really shouldn't be doing that... I think I know why
On Thu, Sep 06, 2012 at 07:13:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-06 at 19:02 +0200, Peter Zijlstra wrote:
> > On Thu, 2012-08-30 at 14:05 -0700, Paul E. McKenney wrote:
> > > From: Frederic Weisbecker
> > >
> > > When exceptions or irq are about to resume userspace, if
> > > the
On Thu, Sep 06, 2012 at 07:13:11PM +0200, Peter Zijlstra wrote:
On Thu, 2012-09-06 at 19:02 +0200, Peter Zijlstra wrote:
On Thu, 2012-08-30 at 14:05 -0700, Paul E. McKenney wrote:
From: Frederic Weisbecker fweis...@gmail.com
When exceptions or irq are about to resume userspace, if
On Thu, 2012-09-06 at 19:02 +0200, Peter Zijlstra wrote:
> On Thu, 2012-08-30 at 14:05 -0700, Paul E. McKenney wrote:
> > From: Frederic Weisbecker
> >
> > When exceptions or irq are about to resume userspace, if
> > the task needs to be rescheduled, the arch low level code
> > calls schedule()
On Thu, 2012-08-30 at 14:05 -0700, Paul E. McKenney wrote:
> From: Frederic Weisbecker
>
> When exceptions or irq are about to resume userspace, if
> the task needs to be rescheduled, the arch low level code
> calls schedule() directly.
>
> At that time we may be in extended quiescent state
On Thu, 2012-08-30 at 14:05 -0700, Paul E. McKenney wrote:
From: Frederic Weisbecker fweis...@gmail.com
When exceptions or irq are about to resume userspace, if
the task needs to be rescheduled, the arch low level code
calls schedule() directly.
At that time we may be in extended
On Thu, 2012-09-06 at 19:02 +0200, Peter Zijlstra wrote:
On Thu, 2012-08-30 at 14:05 -0700, Paul E. McKenney wrote:
From: Frederic Weisbecker fweis...@gmail.com
When exceptions or irq are about to resume userspace, if
the task needs to be rescheduled, the arch low level code
calls
On Thu, Aug 30, 2012 at 02:05:28PM -0700, Paul E. McKenney wrote:
> From: Frederic Weisbecker
>
> When exceptions or irq are about to resume userspace, if
> the task needs to be rescheduled, the arch low level code
> calls schedule() directly.
>
> At that time we may be in extended quiescent
On Thu, Aug 30, 2012 at 02:05:28PM -0700, Paul E. McKenney wrote:
From: Frederic Weisbecker fweis...@gmail.com
When exceptions or irq are about to resume userspace, if
the task needs to be rescheduled, the arch low level code
calls schedule() directly.
At that time we may be in extended
From: Frederic Weisbecker
When exceptions or irq are about to resume userspace, if
the task needs to be rescheduled, the arch low level code
calls schedule() directly.
At that time we may be in extended quiescent state from RCU
POV: the exception is not anymore protected inside
rcu_user_exit()
From: Frederic Weisbecker fweis...@gmail.com
When exceptions or irq are about to resume userspace, if
the task needs to be rescheduled, the arch low level code
calls schedule() directly.
At that time we may be in extended quiescent state from RCU
POV: the exception is not anymore protected
26 matches
Mail list logo
