[LITMUS^RT] RFC: record interrupt interference with Feather-Trace

[Christopher Kenna]

2012/1/30 Björn Brandenburg <bbb at mpi-sws.org>:
> On Jan 30, 2012, at 4:46 PM, Christopher Kenna wrote:
>> The first is the use of the __raw_get_cpu_var function versus the
>> __get_cpu_var function. I was wondering in what situation to use one
>> versus the other? It looks like (from what I could make out in the
>> code) that the two functions differ only when CONFIG_DEBUG_PREEMPT is
>> enabled (the kernel configuration help says something about printing
>> warnings if kernel code uses it in a preemption-unsafe way).
>
> It's not safe to use processor-local variables when preemptions are enabled because your process might be migrated between the time it determines on which CPU it runs and the time that it accesses a processor-local variable.
>
> If CONFIG_DEBUG_PREEMPT is enabled, the kernel will complain if you try to do this. If you use the __raw version, you bypass all checks.
>
> In the case of Feather-Trace, we accept the rare chance of potentially accessing the
> wrong CPU's IRQ flag and CPU id. The IRQ count might be slightly off as a result, but this is unlikely. I don't know if it ever happened, but if it did, it either didn't cause outliers or was filtered.  As commented in the code, if this turns out to be a problem, we could "dirty" the flag in the migration path.

Oh, I get it now. Thanks for the longer explanation (and for the
linked article with the background information, Glenn).

>> The second question is why did you use a barrier in
>> __save_timestamp_cpu and not in save_task_latency? Can the call to
>> litmus_clock in save_task_latency be reordered? (It seems obvious not
>> to use the barrier in __add_timestamp_user, as the time to record is
>> passed in from user space.)
>
> There are atomic instructions in between that serve as implicit barriers. I'm not even sure the barrier in __save_timestamp_cpu is required since ft_timestamp() is also an asm() block.
>
>>
>> Finally, since you suggested it, I pushed our kernel to a private
>> repository on Github. I can add unlimited collaborators to this
>> repository. If you have a Github account and would like to be added,
>> please let me know (Björn, I already added you). I think that using
>> Github for private collaboration is a great idea. The interface they
>> have (even just for diff) is very pretty :) The reason I have this
>> account is because you can request a free Micro account if you are a
>> student, with no limit on the number of collaborators you have
>> <https://github.com/edu>.
>
> I'm not entirely sure why we need a private repository for an open-source project. Anyhow, thanks for setting it up, I'm sure we'll find use for it.

I defaulted to private so as not to imply that this is somehow the
"official" repository. It need not be private, if we decide we don't
want it to be.