linux-kernel - Re: [PATCH] ring_buffer: enlarge RB_MAX_SMALL

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]

Message-ID: <20090415103210.GG6669@elte.hu>
Date:	Wed, 15 Apr 2009 12:32:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	Steven Rostedt <srostedt@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] ring_buffer: enlarge RB_MAX_SMALL_DATA


* Lai Jiangshan <laijs@...fujitsu.com> wrote:

> Steven Rostedt wrote:
> > On Mon, 2009-04-13 at 11:00 +0800, Lai Jiangshan wrote:
> >> When I am writing userspace tools for ftrace, I found
> >> RB_MAX_SMALL_DATA is too small, some events waste an 'u32'
> >> to save the actually length.
> > 
> > Although I like the idea, I want to look at something else.
> > 
> > 2^27 is: 134,217,728
> > 2^26 is: 67,108,864
> > 
> > That is the count in nanoseconds. Thus we go from 134 millisecs to 67
> > millisecs before we must add an extended counter.
> > 
> > I guess that is not an issue, since 67ms is still quite big. For sparse
> > tracing, it could add more extended counters where none were needed. But
> > this I doubt this is an issue.
> 
> 67ms < 0.1sec, It sounds not very good.
> 
> > 
> >> This fix will break previous userspace tools,
> >> so complaints are also welcome.
> > 
> > Unfortunately, this changes the API to userspace. For those parsers that
> > do this in binary. I think the answer is, before we add this, we export
> > the format of the ring buffer headers just like we do for other formats.
> > This way, a user tool can default to the old way if the format file does
> > not exist, and can know the current format with the file.
> > 
> > I'll work on adding that format file sometime this week.
> >
> 
> I think ftrace is still in develop-circle, changing its API to 
> userspace is sometimes OK. Will you agreed this fix after you add 
> that format file? It saves about 0%-12%(depends on tracer) memory.

Yes, /debug APIs can be changed indeed.

And compressing tracer memory consumption is a high priority design 
target: lower memory consumption doesnt just mean less RAM footprint 
and less disk footprint, it also means less CPU cache footprint, 
less intrusive tracing, faster tracing, etc. etc.

So compression is a very important goal - and we only want to stop 
doing it when the direct CPU overhead or the compression complexity 
it introduces offsets the size win. In this particular case we are 
still far from that cutoff point IMHO.

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