RE: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)

• Previous message: Ingo Molnar: "Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]"
• In reply to: Alan Cox: "RE: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)"
• Next in thread: Chris Wright: "Re: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)"
• Reply: Chris Wright: "Re: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>, "Andrew" <aathan-linux-kernel-1542@cloakmail.com>
Date:	Fri, 29 Oct 2004 12:43:11 -0400

Alan:

Thanks for your note. The application in question is not "hard RT" and I am using SCHED_RR to improve latency, rather than
guarantee a particular latency number. Also, since I am using the ACE framework, and don't have the time to detangle its
protability preprocesor macros to add support for a different futex/mutex mechanism, I'm inclined to use stock code. I did dig up
Inaky's work which is a fusyn mapping to existing futex calls--I might try that.

However, would any of that really solve this problem? That is, do lower priority non-RR tasks and/or kernel signal delivery benefit
from additional scheduled time under those patches?

I suspect what is happening here is that my process is essentially in a

while(1)
{
  lock();
  unlock();
}

loop from two or mode SCHED_RR threads running at nice -15. They seem to be unkillable.

However, should we really dismiss the possibility that the problem could be that these threads are in some kind of deadlock that
involves the scheduler?

A.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Alan Cox
Sent: Friday, October 29, 2004 11:07 AM
To: Andrew
Cc: Linux Kernel Mailing List; roland@topspin.com; Andrew Morton
Subject: RE: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)

On Gwe, 2004-10-29 at 15:26, Andrew wrote:
> Although it appears I need to fix an applicaiton bug, is it normal/desirable for an application calling system mutex facilities to
> starve the system so completely, and/or become "unkillable"?

If it is SCHED_RR then it may get to hog the processor but it should not
be doing worse than that and should be killable by something higher
priority.

You are right to suspect futexes don't deal with hard real time but the
failure you see isnt the intended failure case.

[Inaky has posted some drafts of a near futex efficient lock system that
ought to work for real time use btw]

Alan

-
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/

-
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/

• Previous message: Ingo Molnar: "Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]"
• In reply to: Alan Cox: "RE: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)"
• Next in thread: Chris Wright: "Re: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)"
• Reply: Chris Wright: "Re: Consistent lock up 2.6.10-rc1-bk7 (mutex/SCHED_RR bug?)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]