[lkml]   [2005]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: read() on relayfs channel returns premature 0
On Thu, Mar 24, 2005 at 01:11:39PM -0600, Tom Zanussi wrote:
> Kingsley Cheung writes:
> > On Wed, Mar 23, 2005 at 09:29:12AM -0600, Tom Zanussi wrote:
> > > writes:
> > > >
> > > > Now I understand that this is not the latest release of relayfs (there
> > > > are the redux patches, which I have yet to try). Nonetheless I'd like
> [...]
> >
> > I've tested it on 2.6.10 with the pagg and relayfs patches from
> >
> >
> >
> > and
> >
> >
> >
> > read() gives me a zero still once about a page of data has been read.
> >
> Thanks - I've tried it out and haven't immediately been able to
> reproduce the problem yet - I'll do some more pounding on it though
> when I get the chance.

Ok. It should be fairly easy to reproduce. On a dual 400MHz PII I've
been able to get the zero by running one reader of the channel in
parallel with a simple shell script like "while :; do ps -ef >
/dev/null; done".

> BTW, I just want to point out that there aren't any problems with
> read() in the version of relayfs included in the -mm tree (i.e. the
> 'redux' version), since of course it doesn't support read().


> I went ahead and did a quick port of your stuff to the new version of
> relayfs, which you can find here:
> There's a README in the tarball with some notes on building and
> running it. It includes both the kernel and user-side code, which makes
> use of the relay-apps code and documentation found here (I've included
> the necessary files in the RelayfsModule-new tarball so you don't have
> to actually get this):
> Hopefully the new version will still be useful for what you're trying
> to do, but it does differ in a couple important ways from the old
> version, and points up the fact that the new relayfs really is now
> much more specialized for high-volume applications -
> - your old version used 'packet' mode with read(). The new relayfs
> only supports 'bulk' mode with mmap(), which means it's not really
> useful for notification of single events. I'm not sure how important
> that is for your application - if you're mainly interested in
> collecting data, you can certainly use it even for low-volume
> applications, but the events will be sent to user space in 'blocks'.
> You can modify the user space app to process blocks of events as they
> come in, and play around with buffer sizes to get them more often, but
> it's not quite the same thing.
> - your old version used a single buffer, while the new relayfs only
> supports per-cpu buffers, which means you'd have to sort out the
> events in user space and impose some ordering using timestamps for
> instance if your data doesn't already have a natural ordering (BTW,
> the new relayfs doesn't have an option any longer to do automatic
> timestamping either).

Right. Thanks for all your work on it Tom . I really appreciate it.
I have been considering a move over to the redux version recently.
Your port will make it easier for me to test both versions out. I'll
keep your pointers in mind.

> I'll continue maintaining the old relayfs for existing users (so
> thanks for the patch and the test code) so if the new version doesn't
> fit your needs, you'll still have the old version to fall back on.
> Thanks,
> Tom

Ok. Thanks again!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean