Re: read() on relayfs channel returns premature 0

[Kingsley Cheung <kingsley@aurema.com>]

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:
>  > > kingsley@aurema.com 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
>  > 
>  > http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-2.6.10-050113 
>  > 
>  > and
>  > 
>  > ftp://oss.sgi.com/projects/pagg/download/linux-2.6.10-pagg.patch-4
>  > 
>  > 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().

Ok.

> I went ahead and did a quick port of your stuff to the new version of
> relayfs, which you can find here:
> 
> http://prdownloads.sourceforge.net/dprobes/RelayfsModule-new.tar.bz2?download
> 
> 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):
> 
> http://prdownloads.sourceforge.net/dprobes/relay-apps-0.2.tar.gz?download
> 
> 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!
-- 
		Kingsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/