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
> 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?
No. If the data read is not in cache and if read operations causes page
fault there will be process switch.
Additionally, if you don't mlock memory, there can be process switch at
any place, because of page faults on code pages or swapping of data pages.
> 2) What if the process was a non-realtime processes (ordinary
> one, SCHED_OTHER)?
There can be process switches too.
Mikulas
--- Mikulas Patocka
<[email protected]> escreveu: > > 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?
>
> No. If the data read is not in cache and if read
> operations causes page
> fault there will be process switch.
>
> Additionally, if you don't mlock memory, there can
> be process switch at
> any place, because of page faults on code pages or
> swapping of data pages.
I was reading the book "Understanding the Linux
kernel", about 2.4, and the authors:
1)assure that there is no process switch during
the execution of an eception handler (aka syscall).
they emphasize it.
2) say that the execption handler may not generate
exceptions, except for page faults.
So, if process switching occurs at page faults, I
was wondering which statement is true of if I am
missing sth.
You mentioned page faults due to code. Aren?t the
syscall handlers located in mlocked?
Thanks again
Fabiano
>
> > 2) What if the process was a non-realtime
> processes (ordinary
> > one, SCHED_OTHER)?
>
> There can be process switches too.
>
> Mikulas
>
>
=====
Fabiano Ramos
Mestrando em Engenharia de Sistemas e Computa??o
COPPE / UFRJ
http://www.cos.ufrj.br/~ramosf
[email protected]
______________________________________________________________________
Yahoo! Messenger - Fale com seus amigos online. Instale agora!
http://br.download.yahoo.com/messenger/
Fabiano Ramos <[email protected]> writes:
> kernel", about 2.4, and the authors:
> 1)assure that there is no process switch during
> the execution of an eception handler (aka syscall).
> they emphasize it.
They're wrong. First the system call or exception can
block and then when kernel code returns to user space
it always checks if the time slice hasn't expired.
> 2) say that the execption handler may not generate
> exceptions, except for page faults.
That's also incorrect. e.g. it can generate GPFs
(e.g. when trying to load a segment register supplied
by the user and it is not correct)
and a few other exceptions in extreme cases. Usually
these exceptions are handled without sleeping though.
-Andi
> > > 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?
> >
> > No. If the data read is not in cache and if read
> > operations causes page
> > fault there will be process switch.
> >
> > Additionally, if you don't mlock memory, there can
> > be process switch at
> > any place, because of page faults on code pages or
> > swapping of data pages.
>
> I was reading the book "Understanding the Linux
> kernel", about 2.4, and the authors:
> 1)assure that there is no process switch during
> the execution of an eception handler (aka syscall).
> they emphasize it.
It is wrong. The process switch will occur, if the process blocks waiting
for some resource (disk IO, keyboard, net or similar). Moreover, on 2.6
kernels, if you turn on CONFIG_PREEMPT, process switch in kernel may occur
almost anywhere
> 2) say that the execption handler may not generate
> exceptions, except for page faults.
That's true. Kernel can generate only page fault.
> So, if process switching occurs at page faults, I
> was wondering which statement is true of if I am
> missing sth.
> You mentioned page faults due to code. Aren?t the
> syscall handlers located in mlocked?
Kernel is nonswappable, but when the syscalls returns from kernel, it can
generate page-fault because of its code or data were paged-out.
Mikulas
> Thanks again
> Fabiano
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.
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