Hi mulayadi,
I experienced the same problem .Kernel thread is not giving any chance to other kernel paths to run.
Is it due to non-preemptive kernel.
Thanks,
karunakar
On Thu, Jun 19, 2008 at 3:22 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi ...
first of all, what do you poll there? some register status? could the
On Thu, Jun 19, 2008 at 12:22 AM, Lukas Razik <linux@xxxxxxxxxx> wrote:
> Hello!
>
> I develop a network interface driver and I've the following issue...
>
> I create a kernel thread which has the following thread handler:
> static int com_thread( void *data )
> {
> daemonize( "comthread" );
>
> allow_signal( SIGTERM );
> while( !signal_pending(current) ) {
> if(receive(...)) {
> process_received_data(...);
> }
> }
> complete_and_exit(&threadcomplete, 0);
> }
>
> As you can see, the thread is polling a network card (i.e. Message Queue of
> a SCI network card).
device just yield an interrupt?
And why don't you utilize NAPI here?
Interesting....what preemption model do you use? CMIIW, but I guess
> I know that polling normally is no good idea but the system, where this
> driver shall run on, has 8 cores and we want to reserve exactly one core for
> the polling work to get low latencies...
>
> But now there are two problems:
>
> 1. problem is that the kernel thread doesn't get any signals which are sent
> to it. A possibility is to use a variable instead of
> "!signal_pending(current)" to advise the thread to exit. But I would like to
> know why the thread gets no signals until I insert a sleep function, like
> "msleep(1)", into the while loop.
signal is not delivered because the other code path (i.e tasklet code
or anything that send the signal) didn't have chance to run.
may we know how do you deliver the signal?
maybe because you sometimes:
> 2. problem is the stability of the system. Although there are 7 other "free"
> CPUs which could do the rest of the kernel's work, the system becomes very
> unstable - sometimes it freezes. Why does this happen? I've set the nice
> level of the thread to 19 but this didn't help...
a. hold spinlock too long?
b. disable interrupt too long?
c. hold BKL too long?
Others might suggest better ideas though....
regards,
Mulyadi.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
