Re: [PATCH v4 2/2] Output stall traces in /proc

[Alex Neronskiy]

On Mon, Aug 8, 2011 at 2:37 PM, Don Zickus <dzickus@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/