Hello Mulyadi!
Nice to read you... :-)
# zcat /proc/config.gz | grep PREEMPT
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
i see, and your HZ setting is? 250 I guess?
Right!
Oh, I think you've understood my measuring method in a wrong way...
I don't use jiffies to measure the time (I use do_gettimeofday()) but the
highest time differences are about 4ms (which is one jiffie, if HZ=250),
measured from the netif_rx() call in the kernel to the belonging return of
recvfrom(socket_fd,...) in the userspace.
AFAIK, do_gettimeofday calls do_gettimeoffset...and seems like it
derived time offset based on jiffies.
Hmm... I only know that it has a us precision and it works for me good
enough because the times are the same like with other latency measuring
tools.
I've read this fact (about softirqd) but it seems that do_softirq() won't be
executed... Not even if I do a yield() immediately after netif_rx() in my
kernel thread. I thought the yield() would force the execution of ksoftirqd
which has the same nice value (of +19) like my kernel thread.
As I wrote you: The measured times are between some us and 4ms.
In average I get 2ms.
hm, maybe ksoftirqd needs higher prio....
I don't know why although I yield() my kernel thread and it's the only
process which causes high system load (here) the average times aren't
better because _normally_ after my yield() the ksoftirqd should be
executed as next; I thought...
But O.K. I don't think that I've understood the softirq stuff wrong.
Maybe the scheduler upsets my plans and all other things are more
important than _my_ softirqd. *offended* ;-)
Only if I call do_softirq() explicit after netif_rx() then I get times of
!_about 10us_! in average instead of 2ms.
So, at bottom line this is a solution for us but I wonder why the kernel
doesn't call do_softirq() anyway sooner after the netif_rx() call.
To the best I know, do_softirq "throttles" itself....so if there are
many tasks queued there...it will be pushed to ksoftirqd. So, maybe
sometimes you got bad luck and ksoftirqd waits too long before
executed by scheduler.
That was our thought, too! But we wanted a feedback from a expert.
Time to -rt kernel maybe?
What's that?
I dont't hold any locks and don't disable interrupts.
There's only a while loop in my polling kernel thread...
OK, hope I help you some ways :)
Oh, you helped me this time again, like the last times...
Mulyadi, you're the best - Many Thanks again! :-)
Regards,
Lukas
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
