All of lore.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 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.