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:
> > > [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
