Thread (26 messages) 26 messages, 5 authors, 2014-07-06

Re: Filesystem lockup with CONFIG_PREEMPT_RT

From: Mike Galbraith <hidden>
Date: 2014-06-27 17:35:00
Also in: lkml

Possibly related (same subject, not in this thread)

On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
This seems like a lot of hacks.
It is exactly that, lacking proper pooper-scooper, show rt kernel how to
not step in it.
I'm wondering if it would work if we
just have the rt_spin_lock_slowlock not call schedule(), but call
__schedule() directly. I mean it would keep with the mainline paradigm
as spinlocks don't sleep there, and one going to sleep in the -rt
kernel is similar to it being preempted by a very long NMI.
Problem being that we do sleep there, do need wakeup.  I have a hack
that turns them back into spinning locks, but it.. works too :)
Does a spin_lock going to sleep really need to do all the presched and
postsched work?
It would be lovely if we didn't have to do any of that.  On the IO bit,
I haven't seen hard evidence that the spinlock bit is absolutely
required (better not be, it doesn't guarantee anything), but the
combined hack did kill IO deadlock of multiple filesystems.

-Mike
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help