From: Vegard Nossum <vegard.nossum@oracle.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 10/10] fault injection: inject faults in new/rare callchains
Date: Mon, 8 Aug 2016 16:07:39 +0200 [thread overview]
Message-ID: <57A8922B.70105@oracle.com> (raw)
In-Reply-To: <CAC5umyhggBEQ4e=tfnRCw59c+828cJwUKqq4AbVZw+_cq+S5=Q@mail.gmail.com>
Hi,
On 08/08/2016 03:54 PM, Akinobu Mita wrote:
> 2016-08-04 0:05 GMT+09:00 Vegard Nossum <vegard.nossum@oracle.com>:
>> Before this patch, fault injection uses a combination of randomness and
>> frequency to determine where to inject faults. The problem with this is
>> that code paths which are executed very rarely get proportional amounts
>> of faults injected.
>>
>> A better heuristic is to look at the actual callchain leading up to the
>> possible failure point; if we see a callchain that we've never seen up
>> until this point, chances are it's a rare one and we should definitely
>> inject a fault here (since we might not get the chance again later).
>>
>> This uses a probabilistic set structure (similar to a bloom filter) to
>> determine whether we have seen a particular callchain before by hashing
>> the stack trace and atomically testing/setting a bit corresponding to
>> the current callchain.
[...]
>> +config FAULT_INJECTION_AT_NEW_CALLSITES
>> + bool "Inject fault the first time at a new callsite"
>
> Isn't it better to make a run time configurable option instead of the
> build option?
I prefer a build option personally since it keeps the code simple (you
don't have to dynamically allocate the bitmap of known callchains, for
example). I figured most people using fault injection would enable the
new option while still allowing others to keep the current behaviour
if they really want to.
If you prefer a run-time option I can submit a new version.
Thanks,
Vegard
next prev parent reply other threads:[~2016-08-08 14:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 15:05 [PATCH 01/10] fault injection: fix a few documentation errors Vegard Nossum
2016-08-03 15:05 ` [PATCH 02/10] fault injection: fix Kconfig menu Vegard Nossum
2016-08-03 15:05 ` [PATCH 03/10] fault injection: allow FAULT_INJECTION_STACKTRACE_FILTER on X86_64 Vegard Nossum
2016-08-03 15:05 ` [PATCH 04/10] fault injection: prevent recursive fault injection Vegard Nossum
2016-08-03 15:05 ` [PATCH 05/10] fault injection: mutex_trylock() " Vegard Nossum
2016-08-03 16:07 ` kbuild test robot
2016-08-03 18:15 ` kbuild test robot
2016-08-03 15:05 ` [PATCH 06/10] fault injection: rt_mutex_trylock() " Vegard Nossum
2016-08-03 15:05 ` [PATCH 07/10] fault injection: down_trylock() " Vegard Nossum
2016-08-03 15:05 ` [PATCH 08/10] fault injection: down_{read,write}_trylock() " Vegard Nossum
2016-08-03 15:05 ` [PATCH 09/10] fault injection: spin_trylock() " Vegard Nossum
2016-08-03 22:02 ` kbuild test robot
2016-08-03 22:11 ` kbuild test robot
2016-08-03 15:05 ` [PATCH 10/10] fault injection: inject faults in new/rare callchains Vegard Nossum
2016-08-08 13:54 ` Akinobu Mita
2016-08-08 14:07 ` Vegard Nossum [this message]
2016-08-08 16:24 ` Akinobu Mita
-- strict thread matches above, loose matches on Subject: below --
2016-10-16 15:56 [PATCH 01/10] fault injection: fix a few documentation errors Vegard Nossum
2016-10-16 15:56 ` [PATCH 10/10] fault injection: inject faults in new/rare callchains Vegard Nossum
2016-10-21 0:32 ` Akinobu Mita
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=57A8922B.70105@oracle.com \
--to=vegard.nossum@oracle.com \
--cc=akinobu.mita@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox