Messages in this thread | | | From | "Michael Clarke" <> | Subject | System calls and scheduling | Date | Thu, 5 Mar 1998 09:45:30 -0000 |
| |
Hello all LINUX kernel kings !
Okay, Im beaten ! Im studying the LINUX kernel sources (v2.0.30) in conjunction with the book "LINUX Kernel Internals" by Beck et al. Im trying to get a handle on system calls in LINUX and how they tie in with scheduling. First Im making a couple of assumptions (which may be wrong !) 1) System calls execute (in _system_call()) with interrupts enabled because INT 0x80's IDT segment descriptor is of trap gate type (type 15 1111b) rather than interrupt gate type (as used for h/w interrupts). 2) System calls CANNOT be interrupted by other processes (but they can be interrupted by h/w interrupts e.g. timer) because other processes cannot execute* while a system call is in progress, unless the process blocks on say interruptible_sleep_on() - in which case it is no longer executing anyway.
* I want to know why another process cant / doesnt execute while one process is in the middle of a system call but is not blocked. It looks to me like the schedule() function could preempt the system_call() for an end of time-slice event, thus allowing someone else to perform a system call perhaps racing the pre-empted one.
The reason I say this is because of the way that timer_interrupt() / do_timer() seems to work...
If the timer interrupt calls ret_from_sys_call() on each timer interrupt then the timer bottom half is executed and the current process is tested for quanta expiry i.e. p->counter <0. If resheduling is needed then resched is set, and ret_from_sys_call() detects this and calls schedule(). This is fine for processes executing user code. BUT it seems that a process executing a system call when a timer interrupt is received could also be pre-empted by quanta expiry, thus a new process is scheduled while one is in mid-flow in a system call. This breaks my rule 2) above !!!
What *I* see in the code is that do_timer does not check for quanta expiry (p->counter < 0) until update_process_times() is called. This is in the bottom half of the timer interrupt and thus will not execute until ret_from_sys_call() is executed. I do not see a ret_from_sys_call() in the timer interrupt ISR in the sources. The book says there should be one (as the timer is a slow interrupt) but does not document it in the code listed. This means that ret_from_sys_call() would never execute until a process completes a full system_call() or blocks inside a system call. This means that processes would never be rescheduled (because the timer interrupt bottom half is not executed to set need_resched to 1 and then call schedule()) unless system calls are being executed by processes (as opposed to calling schedule() at each timer interrupt) --> THIS CANNOT BE CORRECT EITHER !!!
Can anyone set me straight on what I have said - what is the correct model for rescheduling processes particularly in system calls - if this is actually what happens. Am i making wrong assumptions ? Are there some devious macros that expand into ret_from_sys_call() or am I just talking generally crap ?
Cheers for any help offered, Mike
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |