linux-kernel - Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2

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: <20090323202503.GD18774@redhat.com>
Date:	Mon, 23 Mar 2009 16:25:03 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>, utrace-devel@...hat.com,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2

Hi -

On Sun, Mar 22, 2009 at 01:08:11PM +0100, Ingo Molnar wrote:
> [...]
> > In my own limited kernel-building experience, I find the debuginfo 
> > data conveniently and instantly available after every "make".  Can 
> > you elaborate how is it harder for you to incidentally make it 
> > than for someone to download it?
> 
> Four reasons:
> 
> 1)
> 
> I have CONFIG_DEBUG_INFO turned off in 99.9% of my kernel builds, 
> because it slows down the kernel build times significantly: [...]

OK, 15% longer time.

> 2)
> 
> When the kernel build becomes IO-bound [...]
>   without:   870.36 user 292.79 system 3:32.10 elapsed  548% CPU
>   with:      929.65 user 384.55 system 8:28.70 elapsed  258% CPU

OK, lots of network traffic.
 
> 3) [...]
> Try to build 1.6 GB of dirty data on ext3 and run into an fsync() in 
> your editor ... you'll sit there twiddling thumbs for a minute or 
> more.

Now don't go blaming us for ext3 & fsync & not having a low enough
/proc/sys/vm/dirty_background_ratio.


> 4)
> Or yet another metric - Linux distro package overhead. Try 
> installing a debuginfo package: [...]

Same as 3).


> And this download has to be repeated for _every_ minor kernel 
> upgrade.

Actually, no.  If you just want to run the newly built kernel
somewhere else on your network, you can run a systemtap compile server
on your build machine, and let the systemtap network client do ~RPCs
to get at the data.


> The solution?)
> 
> Dunno - but i definitely think we should think bigger:
> 
> The fundamental disconnect i believe seems to come from the fact 
> that most user-space projects are relatively small, so debuginfo 
> bloat is a secondary issue there.

(Well, the fedora debuginfo archive shows a couple of packages of
similar or greater heft than the kernel - openoffice.org, qt3, ...)


> A few random ideas:
> 
> [...] why not build debuginfo on the fly, when a debugging 
> session requires it? Rarely do we need debuginfo for more than a 
> fraction of the whole kernel. [...]
> I mean, lets _use_ the fact that we have source code available, more 
> intelligently. It takes zero time to build detailed debuginfo for a 
> portion of a tree. [...]

Something like that might be made to work.

Note that this backs away from earlier claims that we can make do
without debuginfo, or that the compiler can't be trusted to build the
stuff.  We all agree it'd be nice if made it better and made a little
less.


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