Re: [Xenomai] Message Pipe services behaviour

["Steve M. Robbins" <steve@sumost.ca>]

On Wed, Oct 29, 2014 at 06:30:40PM +0100, Philippe Gerum wrote:
> On 10/29/2014 05:11 PM, Steve M. Robbins wrote:
> 
> > In the old FIFO-based code, we had a suspicion of the similar problem.  Since 
> > the linux process is not real time, we expect multiple messages to be waiting.  
> > To avoid running through the select/read loop once for each message, our old 
> > FIFO-based code opened the file in nonblocking mode and did a read into a buffer 
> > that could hold up to 100 messages.  We generally would read 5-7 at a time, 
> > not 100, so this proved that the reader could keep up when reading in batches.
> > 
> > Using this same technique with the /dev/rtpN end of a Message Pipe never reads 
> > more than 1 message.  I tried both blocking and non-blocking modes but got the 
> > same result.  So this is my main question: knowing that there are likely many 
> > messages in the pipe, how do I read them in a batch?
> > 
> 
> Reading with O_NONBLOCK set on /dev/rtp should do the trick.

Great!  I changed back to O_NONBLOCK (and verified on the running file
using /proc/pid/fdstats).  And I'm using a private pool for the pipe.


> If it does
> not, this could mean that your rt side is filling up the pool too fast
> compared to the scheduling opportunities for the nrt side. The latter
> won't run until the rt activity becomes quiescent long enough.
> 
> You can track how many bytes are readable on the nrt side by using
> ioctl(.., FIONREAD, &some_int), to make sure this value does increase
> over time until ENOMEM is received. Otherwise there must be a leak of
> consumed message buffers.

Good suggestion.  I am now tracking the number of messages available
using the ioctl() just prior to read.  In the most recent run, there
was an average of 83 messages available, but read() only obtained one.
That suggests to me that the nrt side is being scheduled often enough.


I can also see via /proc/xenomai/heap (thanks for the tip!) that the
heap does fill up, so ENOMEM is valid.  When the message rate slows
down, the nrt side is able to catch up and the heap size comes back
down (and ENOMEM goes away).

The previous kernel FIFO-based code actually uses the same code on the
nrt side so I have a bit of confidence in that.  With the FIFO code, I
can see from the ioctl() and read() that it does read all available
bytes.  I'm really puzzled why the rt_pipe is behaving differently.

-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141031/be1ecbbd/attachment.sig>