Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needsit

[Frederic Weisbecker]

On Wed, Mar 28, 2012 at 09:55:37AM +0200, Gilad Ben-Yossef wrote:
> On Wed, Mar 28, 2012 at 5:17 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > On Tue, 2012-03-27 at 21:35 -0400, Steven Rostedt wrote:
> >
> >> > > I call that "lower overhead".
> >> >
> >> > Good marketing but it does not change the facts.
> >
> > I'm replying again because this comment just pisses me off.
> >
> > I'm the only male in my household, living with a wife, two teenage
> > daughters and two bitches (I own two female dogs). This is not the time
> > of month to be arguing with me!
> 
> LOL. I'm married with two daughters. I feel your pain  :-)
> 
> >
> > The fact is, you live in your own little world. You see things from your
> > own little perspective. You can define the time a system call takes as a
> > latency, but that is just one very small aspect of latencies. There's
> > lots of other kinds of latencies and if you did the search I told you
> > to, you would see that. In fact, the latency caused by system calls is
> > such a small niche of the types of latencies there are. I'm not counting
> > the time a system call waits for a device. Although a preempt kernel
> > would be faster for such a case.
> >
> 
> At the risk of butting in on this little flame war, I think it is
> worth mentioning
> that this discussion arouse in the context of of a feature
> (cpuset/nohz) that deals
> with a single task running alone on a CPU and making zero use of
> kernel services,
> from scheduling, through interrupts, to system calls. It's just a pure
> 100% cpu  bound task.

Note that cpu isolation is a specific usecase of nohz cpusets. But it's
intended to be more generally useful (probably for most workloads). That
means we really want to support syscalls, interrupts and everything. That's
why it is called adaptive tickless and not just userspace isolated tickless.

Not that what I'm saying is making the debate on latency moving forward,
I just wanted to ensure there is no misunderstanding of this patchset :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/