public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mike Galbraith <bitbucket@online.de>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Too many rescheduling interrupts (still!)
Date: Wed, 12 Feb 2014 18:46:39 +0100	[thread overview]
Message-ID: <20140212174637.GC5496@localhost.localdomain> (raw)
In-Reply-To: <20140212164356.GB27965@twins.programming.kicks-ass.net>

On Wed, Feb 12, 2014 at 05:43:56PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 12, 2014 at 04:59:52PM +0100, Frederic Weisbecker wrote:
> > 2014-02-12 11:13 GMT+01:00 Peter Zijlstra <peterz@infradead.org>:
> > > On Tue, Feb 11, 2014 at 02:34:11PM -0800, Andy Lutomirski wrote:
> > >> On Tue, Feb 11, 2014 at 1:21 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > >> >> A small number of reschedule interrupts appear to be due to a race:
> > >> >> both resched_task and wake_up_idle_cpu do, essentially:
> > >> >>
> > >> >> set_tsk_need_resched(t);
> > >> >> smb_mb();
> > >> >> if (!tsk_is_polling(t))
> > >> >>   smp_send_reschedule(cpu);
> > >> >>
> > >> >> The problem is that set_tsk_need_resched wakes the CPU and, if the CPU
> > >> >> is too quick (which isn't surprising if it was in C0 or C1), then it
> > >> >> could *clear* TS_POLLING before tsk_is_polling is read.
> > >
> > > Yeah we have the wrong default for the idle loops.. it should default to
> > > polling and only switch to !polling at the very last moment if it really
> > > needs an interrupt to wake.
> > >
> > > Changing this requires someone (probably me again :/) to audit all arch
> > > cpu idle drivers/functions.
> > 
> > Looking at wake_up_idle_cpu(), we set need_resched and send the IPI.
> > On the other end, the CPU wakes up, exits the idle loop and even goes
> > to the scheduler while there is probably no task to schedule.
> > 
> > I wonder if this is all necessary. All we need is the timer to be
> > handled by the dynticks code to re-evaluate the next tick. So calling
> > irq_exit() -> tick_nohz_irq_exit() from the scheduler_ipi() should be
> > enough.
> 
> No no, the idea was to NOT send IPIs. So falling out of idle by writing
> TIF_NEED_RESCHED and having the idle loop fixup the timers on its way
> back to idle is what you want.

Ok but if the target is idle, dynticks and not polling, we don't have the choice
but to send an IPI, right? I'm talking about this kind of case.

  reply	other threads:[~2014-02-12 17:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 20:23 Too many rescheduling interrupts (still!) Andy Lutomirski
2014-02-11 21:21 ` Thomas Gleixner
2014-02-11 22:34   ` Andy Lutomirski
2014-02-12 10:13     ` Peter Zijlstra
2014-02-12 15:49       ` Andy Lutomirski
2014-02-12 16:39         ` Peter Zijlstra
2014-02-12 18:19           ` Andy Lutomirski
2014-02-12 20:17             ` Peter Zijlstra
2014-02-13  1:40               ` [RFC] sched: Add a new lockless wake-from-idle implementation Andy Lutomirski
2014-02-13  9:38                 ` Ingo Molnar
2014-02-13 14:49                 ` Frederic Weisbecker
2014-02-13 14:50                 ` Peter Zijlstra
2014-02-13 17:07                   ` Andy Lutomirski
2014-02-13 20:16                     ` Peter Zijlstra
2014-02-13 20:35                       ` Andy Lutomirski
2014-02-13 19:58                   ` Andy Lutomirski
2014-02-14  1:38                     ` Andy Lutomirski
2014-02-14 20:01                   ` Andy Lutomirski
2014-02-14 20:17                     ` Andy Lutomirski
2014-02-14 21:19                       ` Peter Zijlstra
2014-02-12 15:59       ` Too many rescheduling interrupts (still!) Frederic Weisbecker
2014-02-12 16:43         ` Peter Zijlstra
2014-02-12 17:46           ` Frederic Weisbecker [this message]
2014-02-12 18:15             ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140212174637.GC5496@localhost.localdomain \
    --to=fweisbec@gmail.com \
    --cc=bitbucket@online.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox