From: Ingo Molnar <mingo@elte.hu>
To: Sripathi Kodi <sripathik@in.ibm.com>
Cc: Darren Hart <dvhltc@us.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH 0/2] Futex fault injection
Date: Wed, 2 Dec 2009 10:19:07 +0100 [thread overview]
Message-ID: <20091202091907.GA22654@elte.hu> (raw)
In-Reply-To: <20091202112801.51af65c0@sripathi>
* Sripathi Kodi <sripathik@in.ibm.com> wrote:
> On Tue, 1 Dec 2009 17:23:59 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
>
> >
> > * Darren Hart <dvhltc@us.ibm.com> wrote:
> >
> > > I don't think the "butt-ugly" argument is enough to reject the patch.
> >
> > It is in my book - i dont ever apply ugly patches intentionally.
> >
> > > It's a fairly subjective metric and I don't think the proposed
> > > solution results in "pretty" code either. In fact the super long
> > > function names and multi-line conditionals are arguably "ugly" (maybe
> > > not "butt-ugly" though). :-)
> > >
> > > However, the arguments are solid and I understand wanting to introduce
> > > a new feature in a particular way. Has there been any work done on
> > > perf event injection up to this point or would this be a completely
> > > new perf feature?
> >
> > Yeah, it would be a brand new one.
> >
>
> Fault injection framework currently in the kernel provides an
> infrastructure to set parameters like 'probability', 'interval',
> 'times' as well as a task filter. I think a fault injection mechanism
> using tracepoints-perf will also need to provide such a framework,
> because without that the faults become too predictable. For example,
> if there are 20 fault points in the kernel, we should be able to
> trigger any one of them with a given probability, possibly for a
> particular task alone. This infrastructure will have to be built in
> perf tools in user space. Do you agree?
Yeah, definitely so. I think event injection is ultimately useful and
should/could graduate/extend from its current rather limited debugfs
based API to something syscall based (which perf could offer). App
testsuites could programmatically inject faults, etc.
The act of logging/tracing/profiling events and the act of injecting
events is ultimately connected.
Btw., 'perf task filter' is something inherent in perf events: you can
define per task (or per cpu, or per task hierarchy) events.
Ingo
prev parent reply other threads:[~2009-12-02 9:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 8:46 [RFC] [PATCH 0/2] Futex fault injection Sripathi Kodi
2009-12-01 8:49 ` [RFC] [PATCH 1/2] Futex fault injection: Add fault points Sripathi Kodi
2009-12-01 8:51 ` [RFC] [PATCH 2/2] Futex fault injection: Config option Sripathi Kodi
2009-12-01 10:33 ` [RFC] [PATCH 0/2] Futex fault injection Ingo Molnar
2009-12-01 10:54 ` Peter Zijlstra
2009-12-01 12:55 ` Ingo Molnar
2009-12-01 16:16 ` Darren Hart
2009-12-01 16:23 ` Ingo Molnar
2009-12-02 5:58 ` Sripathi Kodi
2009-12-02 9:19 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091202091907.GA22654@elte.hu \
--to=mingo@elte.hu \
--cc=dvhltc@us.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sripathik@in.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.