Date: Mon, 19 Apr 2004 21:32:15 -0400 (EDT)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: root@chaos.analogic.com
To: Fabiano Ramos <fabramos@bol.com.br>
cc: linux-kernel@vger.kernel.org
Subject: Re: task switching at Page Faults
In-Reply-To: <1082399579.1146.15.camel@slack.domain.invalid>
Message-ID: <Pine.LNX.4.53.0404192127240.8297@chaos>
References: <1082399579.1146.15.camel@slack.domain.invalid>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1461
Lines: 43

On Mon, 19 Apr 2004, 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?
>
> 	2) What if the process was a non-realtime processes (ordinary
> one, SCHED_OTHER)?
>
>
> Thanks a lot.
> Fabiano


Read() from a device will probably sleep so you will certainly
end up losing the CPU while the data are being fetched. You can
prevent any of your processes pages from being faulted out.
See mlockall() and friends.

Normally, a system call does not cause a context switch. The kernel
handles the requirements of the caller in the context of the caller
just like a library. BUT.... If the kernel needs to wait for something,
it will always give the CPU to some runable task. That causes a
context-switch. The kernel does not busy-wait, i.e, spin.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5596.77 BogoMips).
            Note 96.31% of all statistics are fiction.


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