[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    [W:0.026 / U:3.380 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site