Hello Mulyadi!
Mulyadi Santosa wrote:
So, I have these questions:
1. Why does the yield() call in my kernel thread not force the proceeding of
the softirqs?
AFAIK , jiffies is updated as a part of bottom halves too (softirqd
IIRC). Thus, further suspicion should be directed to "what's your
current active preemption mode"? I guess it could be voluntary
preemption. Try full preemption and see the difference.
I use the following preemption (krenel v.2.6.22):
# 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
Beyond that, i suggest to use rdtsc() to get better timing
granularity. Jiffies...limits you to 1ms precision....assuming you use
HZ=1000. Further if you use no_hz, there is a chance that jiffies
wouldn't be updated for relatively long ticks.
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.
2. Is it normally 'safe' to call do_softirq() in a kernel thread?
What should I take into account?
I think normally you won't need to do that. do_softirq will be called
everytime the kernel is finished dealing with interrupts or executing
ksoftirqd.
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.
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.
So maybe what you need is to "break off" any potential long
code path. By "breaking off", i mean do things like don't hold lock
too long, don't disable interrupt too long and so on.
I dont't hold any locks and don't disable interrupts.
There's only a while loop in my polling kernel thread...
Many Thanks for your answer and your suggestions!
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
