Messages in this thread | | | Date | Mon, 8 Aug 2011 16:34:33 -0700 | Subject | Re: [PATCH v4 2/2] Output stall traces in /proc | From | Alex Neronskiy <> |
| |
On Mon, Aug 8, 2011 at 2:37 PM, Don Zickus <dzickus@redhat.com> wrote: > Maybe irq_work isn't what we needed. I just wasn't smart enough to figure > out how to make sure we can write data in an NMI context and read it in a > normal context. I supposed the whole swapping buffers could work and is > simpler. So each of the buffers has its own lock, right? If a lock protects a pair of buffers, then: A reader takes the lock, and a writing NMI comes in and writes to the non-readable buffer and swaps the two. The reader still has the lock. Another NMI comes in, sees that the lock is unavailable, and writes to the "backup" buffer, which is actually the one the reader is still reading from. Bad corrupted read results.
Either way, I don't see how to make the idea work safely for one pair of buffers shared by multiple CPU's. It works one-pair-per-CPU, but that's not how the current design is. I guess it would need to add/remove files every time a processor is added/removed, and there have to be some other changes too, obviously. What do you think, Don? Should this be a per-CPU thing, instead of global worst?
Other alternatives: 1. Try lock. The interrupts will simply not save their data if they are locked out by readers. 2. Work queue + dynamic allocation. No, I don't mean irq_work. This works, doesn't it? But it's a bit wasteful of cycles and memory. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |