lkml.org 
[lkml]   [2005]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Xterm Hangs - Possible scheduler defect?
"Chad N. Tindel" <chad@tindel.net> wrote:
>
> > `xterm' is waiting for the other CPU to schedule a kernel thread (which is
> > bound to that CPU). Once that kernel thread has done a little bit of work,
> > `xterm' can terminate.
> >
> > But kernel threads don't run with realtime policy, so your userspace app
> > has permanently starved that kernel thread.
> >
> > It's potentially quite a problem, really. For example it could prevent
> > various tty operations from completing, it will prevent kjournald from ever
> > writing back anything (on uniprocessor, etc). I've been waiting for
> > someone to complain ;)
> >
> > But the other side of the coin is that a SCHED_FIFO userspace task
> > presumably has extreme latency requirements, so it doesn't *want* to be
> > preempted by some routine kernel operation. People would get irritated if
> > we were to do that.
> >
> > So what to do?
>
> It shouldn't need to preempt the kernel operation. Why is the design such that
> the necessary kernel thread can't run on the other CPU?
>

This particular kernel function is implemented via a kernel thread per CPU,
with each thread bound to each CPU. The xterm-does-exit cleanup code is
waiting for the thread which is bound to the busy CPU to do something.

No other CPU can, or is allowed, to do that thread's work. If it were to
do so, the implicit locking which we get from the per-cpuness would be
violated.

I don't know if any clients of the workqueue code rely upon the
pinned-to-cpu feature.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.220 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site