From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lists linaro-kernel <linaro-kernel@lists.linaro.org>
Subject: Re: [Query]: tick-sched: why don't we stop tick when we are running idle task?
Date: Tue, 15 Apr 2014 11:30:04 +0200 [thread overview]
Message-ID: <20140415093002.GL1877@localhost.localdomain> (raw)
In-Reply-To: <20140414120600.GJ11096@twins.programming.kicks-ass.net>
On Mon, Apr 14, 2014 at 02:06:00PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 14, 2014 at 05:22:30PM +0530, Viresh Kumar wrote:
> > On 14 April 2014 17:17, Peter Zijlstra <peterz@infradead.org> wrote:
> > > What causes this tick? I was under the impression that once there's a
> > > single task (not doing any syscalls) and the above issues are sorted, no
> > > more tick would happen.
> >
> > This is what Frederic told me earlier:
> >
> > https://lkml.org/lkml/2014/2/13/238
>
> That's a bit of a non-answer. I'm fairly sure its not a gazillion
> issues, since the actual scheduler tick doesn't actually do that much.
>
> So start by enumerating what is actually required.
Ok, I'm a bit buzy with a conference right now but I'm going to summarize that
soonish.
>
> The 2), which I suppose you're now trying to implement is I think
> entirely the wrong way. The tick really assumes it runs local, moving it
> to another CPU is insane.
There is probably a few things that assume local calls but last time
I checked I had the impression that it was fairly possible to call sched_class::task_tick()
remotely. rq is locked, no reference to "current", use rq accessors...
OTOH scheduler_tick() itself definetly requires local calls.
next prev parent reply other threads:[~2014-04-15 9:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 10:33 [Query]: tick-sched: why don't we stop tick when we are running idle task? Viresh Kumar
2014-04-09 10:49 ` Viresh Kumar
2014-04-10 14:39 ` Frederic Weisbecker
2014-04-11 10:04 ` Viresh Kumar
2014-04-11 14:53 ` Frederic Weisbecker
2014-04-11 15:18 ` Peter Zijlstra
2014-04-11 16:38 ` Viresh Kumar
2014-04-14 9:48 ` Preeti Murthy
2014-04-14 9:51 ` Viresh Kumar
2014-04-14 11:02 ` Peter Zijlstra
2014-04-14 11:42 ` Viresh Kumar
2014-04-14 11:47 ` Peter Zijlstra
2014-04-14 11:52 ` Viresh Kumar
2014-04-14 12:06 ` Peter Zijlstra
2014-04-15 6:04 ` Viresh Kumar
2014-04-15 9:30 ` Frederic Weisbecker [this message]
2014-04-15 10:52 ` Peter Zijlstra
2014-04-15 10:53 ` Peter Zijlstra
2014-04-23 11:12 ` Viresh Kumar
2014-05-09 8:44 ` Viresh Kumar
2014-05-13 23:30 ` Frederic Weisbecker
2014-05-22 8:44 ` 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=20140415093002.GL1877@localhost.localdomain \
--to=fweisbec@gmail.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.