lkml.org 
[lkml]   [2012]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needs it
From
Date
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!

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.

Having zero preemption in the kernel makes the system calls the fastest.
And to a single thread running by itself on a CPU, this would be the
latency it is most interested in. But a system as a whole, this can
actually be the cause of much larger latencies.

Compile your kernel without preemption (Sever). Use it for a while as a
desktop. Then compile it with CONFIG_PREEMPT, the Preemptible Kernel
option (which in the menu is also called: Low-Latency Desktop!)

Run that for a bit. You'll notice a smoother feeling with the
CONFIG_PREEMPT kernel.

You're talking about overhead not latency. Sure, overhead can cause
latencies, and latencies can cause overhead. What we call latency has
*nothing* to do with marketing. We happen to handle the other 98% of
latencies in the system.

-- Steve





\
 
 \ /
  Last update: 2012-03-28 05:21    [W:0.232 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site