>> >  NACK-ed-by: Ingo Molnar <mingo@elte.hu>
quoted text
>> [...]
>> I wonder why nobody doesn't fix this serious problem until now. [...]

Frankly, the "problem" has not yet been established.  Ingo has failed
to respond to Mathieu's analysis of the actual instruction streams,
which cast doubt on Ingo's technique of simply counting bytes.  So
far, neither Ingo nor Mathieu have published *time measurements* to
quantify the actual (as opposed to speculated) costs.


quoted text
> [...]  furthermore, and because it's Friday again, let me remind
> folks that SystemTap has an even more significant bloat problem: the
> fact that it needs a huge download: [...the dwarf debugging
> information...]

It's a problem, and there are a few improvements under way or being
contemplated:

- compression of the DWARF data to eliminate more duplication
- support for inserting probes only on function entry/exit points
  without debugging data - relying on symbol tables and raw ABI
- a networked service to allow one machine to serve site-wide
  systemtap needs

At the end of the day, lots of information will still need to be
around for those who need to put probes approximately anywhere and to
pull approximately any data out.


quoted text
> for heaven's sake, we can have 3 years of _full Linux kernel
> history_, with all 87875 commits, with full changelog and
> dependencies and full source code included, packed into a rather
> tight, 180 MB git repository

It may seem counterintuitive to you, but remember that object code is
recreated from scratch new every build, yet source code only gradually
(?)  changes.  Try checking in 3 years' builds of stripped object
files into a git repo.


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