Messages in this thread | | | Date | Mon, 19 Apr 2004 21:32:15 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: task switching at Page Faults |
| |
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/
| |