linux-kernel - Re: [PATCH] new irq tracer

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 27 Feb 2009 16:48:22 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	kosaki.motohiro@...fujitsu.com,
	Dominique Toupin <dominique.toupin@...csson.com>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jason Baron <jbaron@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Frank Ch. Eigler" <fche@...hat.com>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, acme@...stprotocols.net
Subject: Re: [PATCH] new irq tracer

> 
> On Fri, 27 Feb 2009, KOSAKI Motohiro wrote:
> > >
> > > In many cases we don't use Linux real-time, we have many systems that
> > > are soft-real-time an non real-time Linux is good enough.
> > >  
> > 
> > Agreed, rt-patch seems off topics. we discuss to mainline kernel.
> 
> The reason I brought up the rt-patch is that Mathieu is concerned about 
> the small latency that happens when we run stop_machine to switch the nops 
> to pointers to trace functions. This latency can be a couple of millisecs, 
> but I can easily make a normal kernel suffer a couple of millisec latency 
> by simply running hackbench (as a normal user).
> 
> The point being, I think Mathieu's point about the latency of enabling the 
> function tracer is frivolous. It is a one time shot that happens when the 
> sysadmin purposely enables the function tracing.  If this is unacceptable, 
> then the system had better be running the rt patch because it will be 
> hitting this unacceptable latency in normal operation.

ok, I missed last thread. thanks.

I think you talk about "ftrace, x86: make kernel text writable only for
conversions" thread, right?
hm, it seems very good discussion.

My concern is, both your and Mathieu's point is fairly reasonable and
good direction.

However, I would bring up another viewpoint. so, 

  - the latency issue can happen actual production server?

Mathieu and Dominique explained ACTUAL production server problem.
but I believe Dominique's server never run hackbench.

In other word, I agree mainline kernel has many latency corner case problems.
but I don't agree corner case existing indicate no need latency improvement.
Generally, actual experience indicate it's valuable to hear them reqirement.

HOWEVER, I still also agree with your disliking messiness.
Then, I would suggest we go into next step.

I mean make the patch of mathieu's plan and mesure it. Then
we can mesure number by number. my number mean,

  (1) How much increasing line and messiness
  (2) How much improving latency

that's fairly comparision and typical lkml discussion style, imho.

What do you think?

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