[Ksummit-discuss] [topic proposal] tracepoints and ABI stability warranties

[Michal Hocko]

On Wed 07-09-16 08:41:23, Vlastimil Babka wrote:
> On 09/07/2016 07:30 AM, Andy Lutomirski wrote:
> > On Sep 6, 2016 10:10 PM, "Al Viro" <viro at zeniv.linux.org.uk
> > <mailto:viro at zeniv.linux.org.uk>> wrote:
> > > 1) piss-poor API is added in form of tracehook.  It exports some
> > information
> > > that can be used to derive something genuinely interesting.  Most of the
> > > time.  Corner cases are unsolvable, even though it might be possible to
> > > provide the interesting part sanely.  Just not in that form.  Moreover,
> > > faking the bits used to derive that information so that existing userland
> > > logics would yield the right result is bloody hard and restricts what we
> > > can do kernel-side, even though the real thing userland wants would
> > not have
> > > such problems.
> > > 
> > 
> > Agreed.
> > 
> > I wouldn't mind a policy that tracepoints are simply never stable.
> > Maybe we should even deliberately change them periodically to drive the
> > point home.
> 
> I would wish that as well. Tracepoints sometimes must expose implementation
> details to be useful for debugging *the implementation*. The tools that use
> them to build some extra interesting metrics on top the tracepoints may
> often need to know even more about the implementation for correct
> interpretation of the data.
> 
> Even if the kernel implementation changes *without* touching the tracepoint
> format, the changed behavior might still destroy these metrics. (I hope it's
> understandable what I'm trying to say, I can't think of a good example right
> now). Do we want to set the implementation in stone to such extent? That
> would suck. If not, then the only way would be to indeed not mainline any
> tracepoints, which would also suck.

Absolutely agreed. As an example just look at the recent reclaim
changes. We no longer do per-zone and replaced it by per-node. This has
required changes to the tracepoint as well. Just look at how
599d0c954f91d0689c9bb421b5bc04ea02437a41 changed
mm_vmscan_lru_shrink_inactive. We definitely do not want to cast our
implementation details into stone.

My recollection is that tracepoints will never be considered a stable
ABI. If we want something stable then we have proper ways to use...

-- 
Michal Hocko
SUSE Labs