Messages in this thread | | | Date | Tue, 17 Jun 2008 08:55:44 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 2/3] relay: Fix race condition which occurs when reading across CPUs. |
| |
* Eduard - Gabriel Munteanu (eduard.munteanu@linux360.ro) wrote: > On Mon, 16 Jun 2008 20:28:44 +0200 > Jens Axboe <jens.axboe@oracle.com> wrote: > > > Hmm dunno, that is what blktrace also did but primarily for > > performance reasons. It's tricky - Tom stated that he is working on a > > lib to abstract this from applications. While that is handy for > > telling you what to do, it also an annoyance that you HAVE to do it > > that way (it's supposed to just be a "normal" fs, not with funky > > restrictions). > > > > So perhaps provide both versions in-kernel and let the kernel user > > device. For blktrace, we have one app and we know we can use the > > faster variant since readers are affine. For more debug style exports > > or where you don't know your consumer, use the safer variant (which > > should be the default action). > > This sounds good. Though short debug info can be exported through > debugfs alone, there is another use to this patch: global channels, > which currently require kernel users to write their own locking > mechanism. > > So, are you fine with me patching relay _and blktrace_ code to use > faster variants named relay_write_affine() and __relay_write_affine()? > This implies having relay_write() and __relay_write() be the slower, > safer paths. Do you agree with this names, provided the functions are > documented correctly? > > kmemtrace will use the affine versions and set CPU affinity anyway, but > it would be nice to have a consistent behavior from relay's part. >
How about not changing the code, not providing a safe version of relay_write, but document its use and what kind of locking the in-kernel user must provide ?
Mathieu
> > Cheers, > Eduard >
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |