lkml.org 
[lkml]   [1998]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectSystem calls and scheduling
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.110 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site