Message-ID: <4084DC4E.3000903@aitel.hist.no>
Date: Tue, 20 Apr 2004 10:16:14 +0200
From: Helge Hafting <helgehaf@aitel.hist.no>
Organization: AITeL, HiST
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
MIME-Version: 1.0
To: Fabiano Ramos <fabramos@bol.com.br>
CC: linux-kernel@vger.kernel.org
Subject: Re: task switching at Page Faults
References: <1082399579.1146.15.camel@slack.domain.invalid>
In-Reply-To: <1082399579.1146.15.camel@slack.domain.invalid>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1156
Lines: 30

Fabiano Ramos wrote:
> Hi all.
> 
> 	I am in doubt about the linux kernel behaviour is this situation:
> supose a have the process A, with the highest realtime
> priority and SCHED_FIFO policy. The process then issues a syscall,
> say read():
> 
> 	1) Can I be sure that there will be no process switch during the
> syscall processing, even if the system call causes a page fault?

A page fault means your realtime process must wait, because the
data it wants isn't available yet. (Data have to be fetched
from disk/device which takes lots of time.)

There is nothing wrong with handing the cpu to some other
lower priority process unser such circumstances, because your realtime
process are stuck and can't use it anyway.

The realtime process wil grab the cpu as soon as it gets ready to run anyway,
I believe the scheduler looks for this sort of thing when the pagefault
eventually completes.

Helge Hafting

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