All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Viktor Stark" <abraar@domain.hid>
To: xenomai@xenomai.org
Subject: [Xenomai-help] [RT_PIPE] - User space read() not waking up
Date: Thu, 22 Mar 2007 22:57:07 +0100	[thread overview]
Message-ID: <20070322215707.232970@domain.hid> (raw)

Hello,

I'm having a little issue with RT pipes and I was wondering if anyone could give me some pointers.

I wrote a RT kernel module for a DAQ card. The DAQ card gets interrupts every 200 us (5 kHz) and I've got a RT interrupt handler which wakes up a RT function (by sending an event to it). Inside that function I use rt_pripe_write to send some data (about 300 bytes) down to user space.

On the user space side, I've got a real small executable which basically opens the pipe via the Xenomai registry and then reads data from it in a tight loop. Inside that loop I read the TSC after each write and I compute a minimum / maximum for a 10 seconds cycle. The problem is that I get a maximum of about 395 us (which is 2 times 200 us approximately). On the kernel side I also do timings and I am 100% sure that my function using rt_pipe_write() is woken up every 200 us (+- 10 us jitter), that is no interrupts are missed.

After further reasearch I realised that I get a maximum value every 10000 cycles, that is every two seconds. I don't have anything in my system (to my knowledge) that has such a period so I'm really confused about what could be causing this.

I tried to have a look at pipe.c in src/nucleus and saw that the user space side is supposed to get woken up on each xnpipe_send() but I admit that I didn't quite catch all the details.

So basically, my question is:
If I have rt_pipe_write() writing to a pipe from a kernel module with a 200 us period and I have a read() in a tight loop reading from that same pipe is user space, what could be the origin of the fact that sometimes my read() doesn't get woken up?

It's worth to mention too, that I'm not losing any data. That is, after the read which eats up 2 cycles, the next read finishes nearly instantaneously (within 5 us) as if only the second rt_pipe_write() woke up the user space read().
Timing illustration (time between read()'s in us): 195 | 200 | 205 | 395 | 5 | 195 | 200 | 200

My setup:
Xenomai 2.2-rc3
Kernel 2.6.17 (with Xenomai compiled in - ie. not compiled as modules)
P4 3GHz - 1Gb RAM
No APM/ACPI/CpuFreq - SMI workaround enabled.
Tried with 2.6.19 / Xenomai 2.3 - same results.

Thanks in advance for any pointers.

Keep up the good work! Xenomai just *rocks*.

Viktor STARK 
-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out


             reply	other threads:[~2007-03-22 21:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-22 21:57 Viktor Stark [this message]
2007-03-23  8:38 ` [Xenomai-help] [RT_PIPE] - User space read() not waking up Jan Kiszka
2007-03-23  8:42 ` Dmitry Adamushko
2007-03-23  8:49   ` Jan Kiszka
2007-03-24  1:48   ` Viktor STARK
     [not found]   ` <460481F2.5010408@domain.hid>
2007-03-24 10:20     ` Dmitry Adamushko
2007-03-24 11:55       ` Philippe Gerum
2007-03-24 12:07         ` Viktor STARK
2007-03-24 22:49           ` Philippe Gerum
2007-03-25  0:23             ` Viktor STARK
2007-03-24 22:36         ` [off-list] " Dmitry Adamushko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070322215707.232970@domain.hid \
    --to=abraar@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.