linux-kernel - Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needs it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1332943322.23924.181.camel@gandalf.stny.rr.com>
Date:	Wed, 28 Mar 2012 10:02:02 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Gilad Ben-Yossef <gilad@...yossef.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linaro-sched-sig@...ts.linaro.org,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Geoff Levand <geoff@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Max Krasnyansky <maxk@...lcomm.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Zen Lin <zen@...nhuawei.org>
Subject: Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needs
 it

On Wed, 2012-03-28 at 09:55 +0200, Gilad Ben-Yossef wrote:
> On Wed, Mar 28, 2012 at 5:17 AM, Steven Rostedt <rostedt@...dmis.org> 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  :-)

Are they teenagers yet? When they become that, the male of the family
becomes the point of frustration relief for them :-p  I've been their
target for the last week. ;-)

> 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.

I perfectly understand, and I said several times that latency has
different meanings for different people. It's as abused as the term
realtime is. I just took offense that he claimed I was using the term as
a marketing ploy.

> 
> For the work loads this is intended for, the time it takes to respond
> to an interrupt
> or context switch to the kernel and back for a system call, is too
> high. It doesn't matter
> how predictable that time is - if the time to do a system call in the
> best possible case
> is too high for you, having that time predictable only means you are
> predictably late :-)

And I agree with this too.

> 
> This is not an observation about Linux, or preempt-rt, or any OS for
> that matter. It's just
> a statement of fact. There is nothing you can do to make the OS better
> to get the time
> lower. It's just a process that doesn't want OS involvement at all
> from the point it is started
> until it's done, except in exception cases. The entire OS is overhead.

Agreed as well.

> 
> The traditional way to deal with these beasts is to run it on bare
> metal with no OS.

I've always said the best realtime OS was DOS ;-)

> What we're discussing is a way to get Linux to give a task bare metal
> like performance.
> That is useful because you can debug and manage the tasks using OS services, but
> still get bare metal like performance. In the context of this
> discussion, *any* kernel
> activity on that CPU during its run time is overhead, really.

Agreed too.

> 
> Preempt-rt is good. I know because I was involved in implementing it
> in a real time
> system that have saved dozen of lives already. When that system misses
> a dead line,
> that is exactly what you get - a line of dead people. Seriously. But
> it works. It just doesn't
> happen to apply here.

And this is why I asked to use the term overhead and not latency. As
latency has different meanings in different contexts, overhead and
determinism are more concrete. Lets stick with those terms so we don't
need to pick the color of the bike shed.

> 
> I don't know if this is what Christoph meant to say, but can we please
> try to get along now? :-)

Oh, I love Christoph. He knows I do. I was just releasing my built up
frustration on him ;-)

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/