The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
Post
Replies:
15
Boosts:
14
god i'm so mad networking gets to describe routing protocols but i can't route my own i/o to my own disk????
The kernel can be logically divided into a top half and a bottom half
Processes cooperate in the sharing of system resources, such as the CPU.
well they don't really cooperate. they're forced to work
The top and bottom halves of the kernel also work together in implementing certain system operations, such as I/O.
sure. valid ✅
Typically, the top half will start an I/O operation, then relinquish the processor; then the requesting process will sleep, awaiting notification from the bottom half that the I/O request has completed.
there is nothing else that can be done
System performance requires that the kernel minimize the overhead in fielding and dispatching a system call.
unimaginative
god i really wish C would just return the int instead of this errno shit
NETWORKING GETS TO INTERRUPT THE KERNEL TOO????
It is also possible to write programs that deliberately synchronize with the system clock to outwit the scheduler.
lol
kind of incredibly strange that stat counting would be implemented by a clock interrupt which stops everything instead of filling up a log buffer of event counts???
An important event is the scheduling that periodically raises or lowers the CPU priority for each process in the system based on that process's recent CPU usage (see Section 4.4).
i don't consider this to be a "scheduler". this is a pencil pusher. a scheduler makes decisions and should incorporate page cache movement along with task scheduling
On a heavily loaded system with many processes, the scheduler may take a long time to complete its job.
a "scheduler" that's linear in the number of processes. genius work
now they have this event queue
The data structure that describes waiting events is called the callout queue.
these are supposedly scheduled with softclock()
honestly i don't get any of this
Other possible approaches include maintaining a heap with the next-occurring event at the top [Barkley & Lee, 1988], or maintaining separate queues of short-, medium- and long-term events [Varghese & Lauck, 1987].
basically my thing is this but the events are tasks and their i/o dependencies
this is completely illogical
The stack is also created from zero-filled memory. Although the stack should not need to be zero filled, early UNIX systems made it so. In an attempt to save some startup time, the developers modified the kernel to not zero fill the stack, leaving the random previous contents of the page instead. Numerous programs stopped working because they depended on the local variables in their main procedure being initialized to zero. Consequently, the zero filling of the
stack was restored.
every damn time anything could be good by asking the user what they want someone decides no
Copying into memory the entire text and initialized data portion of a large program causes a long startup latency.
wouldn't be a problem if you provided a dependency graph structure and the kernel could schedule this before execution
ok so i now understand demand paging is specifically about virtual memory
The system does demand paging by dividing up the address space into equal-sized areas called pages. For each page, the kernel records the offset into the executable file of the corresponding data. The first access to an address on each page causes a page-fault trap in the kernel.
this sounds so complex. what if we didn't do it because we scheduled each task. what then
