public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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