lkml.org 
[lkml]   [2008]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ring-buffer: add paranoid checks for loops

On Thu, 30 Oct 2008, Ingo Molnar wrote:
>
> hm, all those magic constants look a bit like voodoo and make the
> patch ugly, and people who read this will be confused about the
> purpose for sure.

Point taken.

>
> But the checks are still worth having in practice. So could you please
> improve the comments, to come up with some tangible calculation that
> leads to these constants?
>
> For example the '1000' constant, how did you come to that? Could you
> estimate what type of interrupt storm is needed to trigger it falsely?
> So instead of this comment:

My original number was 100,000, but I thought that a bit high ;-)
Since it is OK for an interrupt to preempt this code and perform a trace,
which would make the condition fail by the one being preempted. The
likelyhood of an interrupt coming in at that location 1000 times in a row
seems to be awefully low. It's not enough that a 1000 interrupts come in,
the task being preempted must loop 1000 times and have a trace interrupt
cause the condition to fail each time. I'll explain it this way in the
comments.

I picked a big number because I can see a traced interrupt that is very
active causing several interruptions in this code.

>
> > + * If we loop here 1,000 times, that means we are either
> > + * in an interrupt storm, or we have something buggy.
> > + * Bail!
>
> something like this might look more acceptable:
>
> > + * If we loop here 1,000 times, that means we are either
> > + * in an interrupt storm that preempted the same trace-entry
> > + * attempt 1000 times in a row, or we have a bug in the tracer.
> > + * Bail!
>
> i.e. please exaplain every single magic number there so that it can be
> followed how you got to that number, and what precise effects that
> number has.
>
> In the cases where you just guessed a number based on experiments,
> please think it through and insert an analysis about the effects of
> that number.
>
> Would this be doable?

Again, there are small "allowable" races that causes the code to loop a
few times. I'll try to explain them a bit better in the comments.
There's small races between the reader and writer that can hit just right
to cause a "loop again". But these chances are much smaller than the
interrupt tracing situation.

I'll look deeper at the reasons for the races and explain them a bit
better.

Thanks,

-- Steve



\
 
 \ /
  Last update: 2008-10-30 20:03    [from the cache]
©2003-2011 Jasper Spaans