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

[Björn Brandenburg]

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.

> 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.

- Björn