Messages in this thread | | | Date | Sat, 14 Jun 2008 18:11:03 +0300 | From | Eduard - Gabriel Munteanu <> | Subject | Re: [PATCH 2/3] relay: Fix race condition which occurs when reading across CPUs. |
| |
On Fri, 13 Jun 2008 23:26:41 -0500 Tom Zanussi <tzanussi@gmail.com> wrote:
> Alternatively, you could get rid of the problem by making sure CPU0 > never reads CPU1's data, by having the userspace reader use per-cpu > threads and using sched_setaffinity() to pin each thread to a given > cpu. See for example, the blktrace code, which does this.
Yes, and performance-wise this is better. Though I'm not sure setting affinity is 100% safe. Will the thread be migrated soon enough, so we don't read cross-CPU? The point is I'm not sure how hard this is enforced.
However, I suggest this patch should go in, for two reasons: 1. It provides expected behavior in any such situation. 2. It adds (almost) no overhead when used in conjuction with setting CPU affinity. When the writer acquires the spinlock, it does not busy-wait, so the spinlock just disables IRQs (relay_write()).
> Actually, in a few days or so I'm planning on releasing the first cut > of a library that makes this and all the rest of the nice blktrace > userspace code available to other tracing applications, not just > blktrace. Hopefully it would be something that you'd be able to use > for kmemtrace as well; in that case, you'd just use the library and > not have to worry about these details.
Sounds good. Thanks for letting me know.
Eduard
| |