13 February 2002 Operating Systems ------------------------- ---------------- Linux scheduling two queues - one for real-time, one for regular priority: user level priority or real time credit: initialized to be equal to priority decremented each time quantum executed processes in top priority and same credit run round robin after execute for one quantum, lose one credit weight = credit + priority when all run out of credits, reset to priority recredit, even those blocked on IO credits = credits/2 + priority favors interactive procs because they accumulate credits ---------- Win 2000/NT priority based, preemptive 2 priority bands - real time/variable 16 priority levels in each band real time 16-31 - have priority for life of thread variable 1-15 - decrease priority when use up time quantum raise priority when make IO request raise more for interactive waits (e.g., display, kybd) system level 0 one queue per priority 32 bit bitmask to identify which queues have threads waiting preempt when higher priority thread becomes available e.g., IO completes priority increased when IO request made goals: improve system throughput and responsveness sample boost: disk/cdrom/video +1 n/w, pipe, serial +2 keybd, mouse +6 sound +8 added to base priority never boost real time - keep consistent behavior resumed threads use remaining quantum, then gently decay to base can change quantum - foreground interactive processes get 3x quantum -------------- MultiProcessor scheduling asymmetric - probably master-slave symmetric - options process-based: b/t processors, send other processes a message module-based: modify remote structures directly spin lock to protect queus module - works best on small scale process-based - bigger machines because of physical distribution of memory get proc closer to the op permananently assoc process with processor independent queues could unbalance system common queue master-slave master does all I/O master failes, master bottleneck gang scheduling - coscheduling all threads of same process sched at same time good for barrier based progs not good for client/server or producer/cons hard to schedule correctly - bin packing a lot depends on machine, moving things can be expensive availability of main memory different processor types device needs General research community consensus - processor affinity - keep where was running before good for small bus-based multiprocessors - processor partitioning - semi-permanentla allocate some preocessors to each app - good for large, n/w based machines reality: small multiprocessors: round robin w/ proc. affinity large - do nonstandard, ad hoc homogeneous processors vs. heterogeneous load sharing - common ready queue concurrent access to queue separate reqady queue may leave processor idle master-slave - master schedules slaves master may handle all I/O