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 <[EMAIL PROTECTED]>
wrote:

> Hi ...
>
> On Thu, Jun 19, 2008 at 12:22 AM, Lukas Razik <[EMAIL PROTECTED]> 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).
>
> first of all, what do you poll there? some register status? could the
> device just yield an interrupt?
>
> And why don't you utilize NAPI here?
>
> > 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.
>
> Interesting....what preemption model do you use? CMIIW, but I guess
> 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?
>
> > 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...
>
> maybe because you sometimes:
> 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 [EMAIL PROTECTED]
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>

Reply via email to