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

[Alex Neronskiy]

On Tue, Aug 9, 2011 at 2:08 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote:
> Well, looking at the code again, I think the spin_locks in the NMI handler
> will block the other cpus from writing to the page at the same time.  So
> it gets serialized that way, I think.  The next trick is to do something
> with procfs like swapping buffers successfully.
>
> I am trying to think how that would work, but I guess if you use the
> cmpxchg macros then
>
> procfs could cmpxchg a READ_BIT on the buffer and if successful (no
> WRITE_BIT), then proceed to read the buffer.  Otherwise use the other
> buffer.  A lock would have to be used to serialize access on the procfs.
>
> The NMI code could do the same with a WRITE_BIT and if succesful (no
> READ_BIT), then proceed to write the buffer.  Otherwise use the other
> buffer.  Because the NMI is serialized only one write could go on at any
> one time.
>
> I was reading the kernel/irq_work.c code to generate the above idea.
>
> Not sure if it works.  Thoughts?
>
> Cheers,
> Don
>
I don't think that the reader should use the other buffer if it finds
contention. Who knows what that other buffer contains? Maybe something
really stale, maybe nothing. However, I think it's okay for the reader
to wait to be able to obtain the lock from the writer; just not the
other way around. I have a similar idea sketched out and I'll try and
get a patch out soon. Basically, the reader will be really simple and
just obtain the lock on whatever buffer it's told and then read that
buffer and unlock. The worst that will happen is that it will read a
slightly stale value, and that's only because it read "before" the
buffers switched. The writer, meanwhile, merely tries to lock a
buffer, and if it fails, sets the other one as the writable one (this
state is not shared with the reader). Then it locks that one
(guaranteed no contention), writes out the data, tells the reader to
read from the new buffer from now on, and unlocks. Both readers and
writers are serialized.

It's probably pretty hard to follow that description. Hopefully the
patch will be clearer.
--
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/