Message-ID: <3E4A9F13.40705@nortelnetworks.com>
Date: Wed, 12 Feb 2003 14:22:59 -0500
From: Chris Friesen <cfriesen@nortelnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: possible to livelock in mprotect() syscall?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1665
Lines: 48


Is it possible for ksoftirqd to have hold of some resource that other 
processes may need to obtain in the mprotect() syscall?

The background for this is as follows:

I've done some work with modifying the linux scheduler to support 
additional scheduling classes with limits on cpu percentages available 
for each class under stress.

We're hitting a strange scenario under the following conditions:

sched class A is given 90% of the cpu and is based on strict static 
priority scheduling

process x is put in sched class A with and is event driven

process y is put in sched class A with a lower priority than x and is a 
cpu hog

We would expect to see a background of y running, interrupted by x when 
it becomes runnable.

We seem to be seeing a case where process x calls mprotect() and then 
blocks while process y runs for large amounts of time.  Eventually we 
see ksoftirqd run and immediately after that process x wakes up and runs 
for a while, but by this time its too late and some timers have expired.

Hence the question--is it possible for ksoftirqd to have hold of some 
resource that process x tries to obtain in the mprotect() syscall?

Thanks,

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

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