Hubbry Logo
Process control blockProcess control blockMain
Open search
Process control block
Community hub
Process control block
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Process control block
Process control block
Process control block
View on Wikipedia
from Wikipedia

A process control block (PCB), also sometimes called a process descriptor, is a data structure used by a computer operating system to store all the information about a process.

When a process is created (initialized or installed), the operating system creates a corresponding process control block, which specifies and tracks the process state (i.e. new, ready, running, waiting or terminated). Since it is used to track process information, the PCB plays a key role in context switching.[1]

An operating system kernel stores PCBs in a process table.[2]

The current working directory of a process is one of the properties that the kernel stores in the process's PCB.[3]

Role

[edit]

The role of the PCBs is central in process management: they are accessed and/or modified by most utilities, particularly those involved with scheduling and resource management.

Structure

[edit]

In multitasking operating systems, the PCB stores data needed for correct and efficient process management.[4] Though the details of these structures are system-dependent, common elements fall in three main categories:

  • Process identification
  • Process state
  • Process control

Status tables exist for each relevant entity, like describing memory, I/O devices, files and processes.

Memory tables, for example, contain information about the allocation of main and secondary (virtual) memory for each process, authorization attributes for accessing memory areas shared among different processes, etc. I/O tables may have entries stating the availability of a device or its assignment to a process, the status of I/O operations, the location of memory buffers used for them, etc.

Process identification data include a unique identifier for the process (almost invariably an integer) and, in a multiuser-multitasking system, data such as the identifier of the parent process, user identifier, user group identifier, etc. The process id is particularly relevant since it is often used to cross-reference the tables defined above, e.g. showing which process is using which I/O devices, or memory areas.

Process state data define the status of a process when it is suspended, allowing the OS to restart it later. This always includes the content of general-purpose CPU registers, the CPU process status word, stack and frame pointers, etc. During context switch, the running process is stopped and another process runs. The kernel must stop the execution of the running process, copy out the values in hardware registers to its PCB, and update the hardware registers with the values from the PCB of the new process.

Process control information is used by the OS to manage the process itself. This includes:

  • Process scheduling state – The state of the process in terms of "ready", "suspended", etc., and other scheduling information as well, such as priority value, the amount of time elapsed since the process gained control of the CPU or since it was suspended. Also, in case of a suspended process, event identification data must be recorded for the event the process is waiting for;
  • Process structuring information – the process's children id's, or the id's of other processes related to the current one in some functional way, which may be represented as a queue, a ring or other data structures;
  • Interprocess communication information – flags, signals and messages associated with the communication among independent processes;
  • Process Privileges – allowed/disallowed access to system resources;
  • Process State – new, ready, running, waiting, dead;
  • Process Number (PID) – unique identification number for each process (also known as Process ID);
  • Program Counter (PC) – a pointer to the address of the next instruction to be executed for this process;
  • CPU Registers – register set where process needs to be stored for execution for running state;
  • CPU Scheduling Information – information scheduling CPU time;
  • Memory Management Information – page table, memory limits, segment table;
  • Accounting Information – amount of CPU used for process execution, time limits, execution ID etc.;
  • I/O Status Information – list of I/O devices allocated to the process.

Location

[edit]

PCB must be kept in an area of memory protected from normal process access. In some operating systems the PCB is placed at the bottom of the process stack.[5]

See also

[edit]

Notes

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Process control block

View on Grokipedia
from Grokipedia
A process control block (PCB), also known as a task control block, is a kernel-level in operating systems that stores essential metadata about an active , enabling the OS to manage its execution, scheduling, and efficiently. The PCB is created when a process is initiated and persists throughout its lifecycle, serving as the central repository for process-specific details that the OS kernel accesses during operations like context switching. In operating systems, the PCB plays a critical role in multitasking environments by facilitating process state transitions—such as from running to waiting—and ensuring that the correct process context is restored when the CPU is allocated to it. During context switches, the OS saves the current process's state into its PCB and loads the state of the next process from its PCB, preserving elements like the and CPU registers to maintain seamless execution. This mechanism is vital for process scheduling algorithms, which use PCB information to determine priorities and queue positions, thereby optimizing system performance and resource utilization. Key components typically stored in a PCB include:
  • Process state: Indicators such as new, ready, running, waiting, or terminated, reflecting the process's current status.
  • Process identification: Unique process ID (PID), parent process ID, and user ownership details.
  • CPU-related data: (address of the next instruction), CPU register values, and scheduling details like priority and queue pointers.
  • information: Pointers to page tables, segment tables, or allocated memory regions.
  • Accounting and I/O status: CPU usage statistics, time limits, allocated I/O devices, and open file lists.
These elements ensure that the OS can track and control multiple concurrent without interference, forming the backbone of modern process management in systems like Unix, , and Windows.

Overview

Definition

The Process Control Block (PCB) is a kernel-level in operating systems that encapsulates all vital information necessary to represent and manage an individual , including its current state, allocated resources, and execution context such as register values and . This structure serves as the operating system's internal representation of a , allowing the kernel to maintain oversight of system-wide activities without direct access to user-level . The primary purpose of the PCB is to enable the operating system kernel to track, , and control multiple concurrent in a multitasking environment, ensuring orderly execution, resource sharing, and recovery from interruptions like interrupts or system calls. By centralizing metadata in the PCB, the kernel can perform essential operations such as suspending one to resume another, thereby supporting efficient multiprogramming and . Originating from pioneering operating system designs like in the 1960s, which introduced supervisor-managed process queues for , the PCB concept was further formalized in systems such as UNIX during the early 1970s, where it evolved into a process table entry for handling forking and swapping. For instance, in a basic operating system, a PCB might store the unique process ID, state indicator (e.g., ready or running), and priority level to guide scheduling decisions.

Historical Development

The concept of the Process Control Block (PCB) first emerged in the within systems, notably IBM's OS/360, released in 1966, where control blocks were essential for managing job queues and sequential execution of programs. In OS/360, structures such as the Task Control Block (TCB) functioned analogously to a PCB by maintaining details on task status, , and information to handle multiprogramming in non-interactive environments. These early mechanisms laid the groundwork for tracking execution units in resource-constrained mainframe systems, prioritizing efficient job throughput over concurrent user access. A pivotal advancement occurred with , which became operational in 1969 and introduced formal process abstraction through dedicated control blocks for enhanced protection and scheduling. Developed jointly by MIT, , and starting in 1965, Multics employed these blocks to support , enabling multiple users to run isolated processes with segmented addressing for and dynamic during scheduling. This abstraction shifted operating systems toward treating processes as independent entities, influencing subsequent designs by emphasizing security and concurrency in multi-user settings. During the 1970s, UNIX at further refined the PCB by standardizing key fields such as process ID (PID) and CPU registers, promoting robust process handling in environments. Implemented initially on a in 1969 and evolving through versions on PDP-11 systems, UNIX's process table—serving as the PCB—facilitated operations like forking new processes while preserving state information for context switching and signal handling. This standardization by researchers including and established a lightweight, portable model that became foundational for systems. In modern operating systems, the PCB concept evolved into variants like Windows NT's Executive Process Block (EPROCESS), introduced in 1993, which encapsulates , security tokens, and memory mappings for management. Similarly, Linux's task_struct structure acts as a PCB equivalent, with major enhancements including the introduction of the in kernel version 2.6.23 (released October 2007) for advanced scheduling and improved per-process resource tracking. A critical milestone came with the 1988 POSIX.1 standard (IEEE Std 1003.1-1988), which formalized process control interfaces—including creation via () and termination via exit()—to ensure portability across implementations, mandating consistent behavior for PIDs, signals, and execution environments.

Components

Identification and State Information

The Process Control Block (PCB) includes fields for uniquely identifying a , enabling the operating system to distinguish and manage it among concurrent executions. The primary identifier is the Process ID (PID), a unique assigned to each process upon creation, typically a 32-bit signed in modern systems like to accommodate up to millions of processes. PIDs are assigned sequentially by the kernel, starting from low values and recycling freed IDs after a delay to avoid conflicts with lingering references. This sequential allocation supports efficient indexing in process tables and debugging tools. To maintain process hierarchies, the PCB stores the Parent Process ID (PPID), which references the PID of the process that spawned the current one via system calls like fork(). The PPID facilitates tree-like organization of processes, allowing the OS to track dependencies, signal propagation, and resource inheritance across parent-child relationships. For instance, in systems, this linkage ensures that child processes can report status to parents and inherit certain attributes. Process state information in the PCB tracks the operational status of the process, represented as an enumerated value such as new (initially created but not yet admitted), ready (eligible for CPU allocation), running (currently executing), waiting (blocked on an event like I/O), or terminated (completed or aborted). This field often includes sub-details, such as the reason for waiting (e.g., I/O completion or release), to guide the scheduler in resuming the process appropriately. State transitions, like from ready to running during scheduling, are updated atomically in the PCB to reflect dynamic behavior. For security and ownership, the PCB incorporates the User ID (UID) and Group ID (GID), which define the process's privileges and resource access rights. The UID identifies the user account under which the process runs, while the GID specifies the primary group affiliation, with supplementary GIDs for additional permissions; these are stored in a credentials structure referenced by the PCB. In Linux, for example, these values enforce file access controls and system call restrictions based on the effective UID/GID at runtime. In the Linux kernel, the task_struct (the PCB equivalent) includes fields like pid (for PID), real_parent (pointer to parent task for PPID resolution), and state (bitmask for process status), which are initialized and updated during fork() for creation and exec() for program loading.

Execution and Scheduling Details

The execution of a is captured in the process control block (PCB) through key components that preserve the processor state, enabling seamless resumption after interruptions. The (PC) within the PCB holds the of the next instruction the process is set to execute, ensuring continuity when the process regains CPU control. Similarly, the CPU registers section of the PCB stores an array of values, including general-purpose registers, the stack pointer, and status registers, which are critical for maintaining the process's computational state. These elements are saved to the PCB during context switches to prevent loss of execution progress. CPU scheduling information in the PCB encompasses details that guide the operating system's in allocating processor time. This includes priority levels, such as the nice value in systems, which ranges from -20 (highest priority) to 19 (lowest priority) to influence scheduling favoritism. Scheduling classes differentiate process types, for instance, real-time classes like SCHED_FIFO for time-critical tasks versus interactive classes like SCHED_OTHER for general user responsiveness. Additionally, the time quantum specifies the maximum CPU burst duration for the process, often used in algorithms like round-robin to ensure fair sharing. These parameters allow the kernel to make informed decisions on process selection from ready states. To facilitate efficient scheduling, the PCB includes pointers to priority queues, such as links to ready queues organized by priority levels for algorithms like round-robin, where are enqueued and dequeued based on their scheduling class and quantum. For example, during a hardware interrupt, the operating system saves the interrupted 's and CPU registers to its PCB, then retrieves and loads the corresponding values from the PCB of the next scheduled , enabling rapid context switching without disrupting overall system performance. This mechanism ensures that execution details remain intact across multiple process preemptions.

Resource Management Data

The resource management data in a process control block (PCB) encompasses fields that enable the operating system to allocate, track, and reclaim resources such as memory, input/output (I/O) devices, and usage metrics for a process. These components ensure efficient resource utilization, prevent conflicts between processes, and support enforcement of limits to maintain system stability. Unlike execution context details, which focus on immediate runtime state, resource management data provides long-term oversight of allocations throughout the process lifecycle. Memory Management Information includes pointers and descriptors that define the process's and boundaries. Key fields typically encompass base and limit registers, which specify the starting address and maximum extent of the process's allocation to enforce isolation. Page tables or segment tables are also stored or referenced here, facilitating virtual-to-physical address translation via the (); for instance, a pointer to the is loaded during context switches to handle paging and segmentation. limits further restrict allocation to prevent overconsumption, such as maximum size tracked in systems like 's mm_struct within the task_struct (the equivalent of a PCB). In segmented architectures, segment descriptors outline , , and stack regions, ensuring and efficient swapping. These elements collectively manage demand paging, frame allocation, and fault handling without exposing physical details to the process. I/O Status Information maintains records of devices and files accessed by the process to coordinate concurrent operations and ensure proper cleanup. This includes a list of allocated I/O devices, such as disks or peripherals, along with their current status (e.g., busy or idle) to manage queues and interrupts. Open files are tracked via descriptor tables, storing file offsets, access modes, and pending requests; in , the files_struct in task_struct holds this table for efficient reference during system calls like read or write. Signal handlers associated with I/O events, such as asynchronous notifications, are also noted to route interrupts appropriately. During process termination, these fields facilitate resource release, such as closing files to free device handles. In Windows, the executive process block (EPROCESS) incorporates a handle table within its ObjectTable field, indexing entries that point to kernel objects like files and memory-mapped sections, enabling secure access and . Accounting Information logs usage statistics and limits to monitor resource consumption and enforce quotas, aiding in billing, scheduling decisions, and overload prevention. Core fields track consumed (user and kernel modes), elapsed wall-clock time since creation, and process identifiers for auditing. Resource limits, such as POSIX's RLIMIT_CPU (maximum CPU seconds before signaling SIGXCPU or SIGKILL), cap usage to avoid monopolization; other limits like RLIMIT_DATA ( size) and RLIMIT_FSIZE (file size) are similarly enforced. In , the taskstats structure aggregates these metrics per task or , including accumulated times and limits for netlink-based reporting. These records support fair allocation across users and detect anomalies without detailed per-instruction logging.

Role in Process Management

Creation and Initialization

The creation of a process control block (PCB) is triggered by specific system calls that initiate a new process in the operating system. In UNIX-like systems, the fork() system call is commonly used to create a child process by duplicating the parent process. In Windows, the CreateProcess() function serves a similar purpose, creating a new process and its primary thread independently of the calling process. Upon invocation of these system calls, the operating system allocates a new PCB structure in kernel memory to manage the process. This allocation is followed by assigning a unique process identifier (PID) to the new process, typically from a pool managed by the kernel. The initial state of the process is set to "new" or "initializing" to indicate it is not yet ready for execution. For processes created via forking, the kernel copies relevant data from the parent's PCB, such as register values, memory limits, and resource pointers, to ensure continuity while establishing the child's identity. In the forking mechanism, the child PCB inherits most fields from the parent but undergoes partial modifications to differentiate it, including resetting user-space pointers to avoid direct sharing of modifiable memory regions. For instance, in Linux, the fork() system call clones the parent's task_struct (the kernel's PCB equivalent) using functions like dup_task_struct() and copy_process(), while updating the parent process ID (PPID) to reference the original parent and clearing flags specific to the child, such as pending signals or resource ownership. This cloning ensures the child starts with a near-identical execution context but operates as a separate entity. If fails during initialization—such as exhaustion of available PIDs or kernel —the creation aborts, and the returns an error code to the caller, preventing an incomplete or invalid from proceeding. Once successfully initialized, the PCB is placed in a ready state for scheduling.

Scheduling and Context Switching

The control block (PCB) plays a central in operating system scheduling by organizing into queues based on their state, such as ready or blocked, allowing the kernel to scan these queues for the next to execute. The kernel updates the PCB of the currently running upon events like interrupts or I/O completion, moving it to the appropriate queue—such as the ready queue if it has remaining time or the blocked queue if awaiting resources—and selects the subsequent based on criteria stored in the PCB, including priority levels and allocated time slices. This queue management ensures efficient , with clock interrupts triggering checks against time slices to lower-priority in favor of higher ones. Context switching relies on the PCB to preserve and restore process execution states seamlessly. When an interrupt or timer expiration occurs, the operating system saves the current process's context—including the (PC), stack pointer, and CPU registers—directly into its PCB, effectively suspending execution. The kernel then selects the next from the ready queue, loading its PCB contents into the CPU registers and PC to resume operation, which detaches the prior process from the processor and attaches the new one. This mechanism, often handled by dedicated routines like save_context() and restore_context(), ensures minimal disruption while maintaining process isolation. Integration with scheduling algorithms further leverages the PCB to maintain fairness and responsiveness. In (MLFQ) systems, the PCB tracks each process's current queue position, priority level, and time allotment usage, enabling dynamic adjustments such as demoting a process to a lower-priority queue after exhausting its slice or promoting it if it yields early. To prevent , priority aging is implemented by periodically boosting all processes to the highest-priority queue—for example, every second in implementations like Solaris—updating the relevant fields in their PCBs to reflect changed behaviors, such as shifting from to interactive workloads. In real-time operating systems like , the task control block (TCB, analogous to a PCB) incorporates deadline fields that guide preemptive scheduling, ensuring tasks meet temporal constraints by prioritizing those with imminent deadlines during queue scans. This approach extends standard priority mechanisms, where the kernel evaluates TCB deadline data to preempt running tasks and select the earliest-deadline successor from ready queues. The overhead of a context switch, involving PCB updates for registers and state, typically ranges from 1 to 10 microseconds, varying with the number of registers saved and hardware architecture, representing a small fraction of overall CPU time in modern systems.

Termination and Cleanup

Process termination in operating systems is initiated through various triggers, including the execution of an exit system call such as exit() in C, which signals the operating system to begin cleanup after the process completes its last statement. Other triggers encompass signals like SIGTERM sent by a parent process or the operating system to terminate a child due to resource limits or task irrelevance, as well as abnormal conditions such as fatal errors or crashes. In cases of parent termination, cascading termination may occur, where the operating system forcibly ends all child processes to maintain system consistency. Upon detecting termination, the operating system updates the process control block (PCB) to reflect the new state, typically marking it as "terminated" to indicate that the process has finished execution and is awaiting resource reclamation. If the parent process has not yet retrieved the child's exit status, the PCB transitions to a "zombie" state, where a minimal entry persists in the process table to preserve the exit code and process ID (PID) for potential querying by the parent via a wait system call. This zombie state prevents immediate PID reuse and ensures the parent can access termination details before full deallocation; once the parent invokes wait, the PID is released for reuse, and the PCB is marked for complete removal. Cleanup actions managed through the PCB involve systematically releasing associated resources to avoid leaks and maintain efficiency. The operating frees memory pages referenced in the PCB's fields, closes open files and handles listed in the I/O status information, and deallocates any exclusive I/O devices or semaphores tied to the process. Accounting statistics, such as CPU time and I/O usage stored in the PCB, are updated and potentially reported to the parent or logs before final reclamation. In the , this cleanup is handled by functions invoked during the exit path, ensuring that structures like the task_struct (equivalent to the PCB) facilitate the release of file descriptors, areas, and signal handlers. In UNIX-like systems, such as , the waitpid() exemplifies this process: it allows the parent to retrieve the child's directly from the PCB, after which the kernel performs full cleanup by removing the PCB entry from the process table and freeing its resources. This mechanism, inherited from early UNIX designs, ensures orderly termination while briefly retaining PCB data only as needed for parent notification.

Implementation Aspects

Storage and Location

The Process Control Block (PCB) is stored in the protected kernel space of the operating 's , isolating it from user-space access to prevent unauthorized modifications and ensure stability. This kernel-resident placement enables the operating to efficiently manage process states, scheduling, and without interference from running applications. PCBs are typically organized within a central called the process table, which serves as a repository for all active processes and facilitates quick retrieval during kernel operations. In older operating systems, such as early Unix implementations, the process table was commonly structured as a fixed-size to support a predetermined maximum number of concurrent , aligning with the limited hardware capabilities and simplifying at the time. This array-based approach allowed direct indexing by process ID but constrained scalability as system demands grew. Modern kernels, however, favor more flexible structures; for instance, maintains PCBs—known as task_structs—in a forming a global task list, which supports dynamic insertion and removal while enabling traversal for system-wide process enumeration. To optimize PID-based lookups, further employs multiple hash tables (one per PID namespace type) that map process identifiers to their task_struct pointers, reducing search times from linear to near-constant. Individual PCBs are dynamically allocated to accommodate variable system loads and process sizes. In Linux, each task_struct is allocated via the slab allocator, a kernel memory management mechanism designed for frequently used objects, ensuring efficient reuse and minimal fragmentation; these structures are several kilobytes in size—for example, around 8 KB in recent kernels (as of 2024)—depending on configuration and . PCBs remain in memory throughout a process's lifecycle, from creation to termination, to support uninterrupted kernel access for critical functions like context switching. In virtual memory environments, kernel memory housing PCBs is not subject to swapping or paging to disk, as it is pinned in physical RAM to guarantee low-latency operations; only user-space memory is eligible for such movement. For example, 's global task list is anchored at the init_task structure, keeping all task_structs persistently available in kernel memory for immediate reference during scheduling. In Microsoft Windows, the equivalent to the PCB is the EPROCESS structure, which is stored in kernel memory as part of the executive objects.

Security and Access Control

The process control block (PCB) is protected by confining it to kernel mode, typically ring 0, where user processes operating in ring 3 cannot directly read or write its contents through pointers or memory access. In , the PCB—embodied in the struct task_struct—resides in kernel space, shielded by the hardware (MMU) that maps kernel addresses as non-executable and inaccessible from user space, triggering faults on unauthorized attempts. Access to PCB data during system calls is mediated by the kernel, which validates requests using the current process's identifier (PID) from its task_struct to ensure only authorized operations, such as signaling or , proceed after permission checks like capability or verification. Process isolation is maintained through user ID (UID) and group ID (GID) fields stored in the PCB's credentials structure (struct cred), which the kernel consults to prevent cross-process resource leaks, such as unauthorized file or memory access by enforcing (DAC). During process creation via , the kernel duplicates the parent's task_struct for the child while employing (COW) for shared memory pages, ensuring initial isolation without immediate full duplication and avoiding inheritance of sensitive state. Vulnerabilities affecting PCB integrity, such as improper handling of credentials during , have been identified and patched; for instance, CVE-2019-13272 in the kernel's subsystem allowed local by mishandling recording in task_struct, which was fixed in version 5.1.17. In systems with (MAC), such as those using SELinux, additional security labels are integrated into the PCB's via (LSM), enabling fine-grained enforcement beyond UID/GID, where process labels dictate allowable interactions with labeled objects like files.

References

  1. https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/3_Processes.html
  2. https://www.eng.auburn.edu/~weishinn/Comp7500/Ch3_Processes.pdf
  3. https://www.cs.cornell.edu/courses/cs3410/2024fa/notes/process.html
  4. http://personal.kent.edu/~rmuhamma/OpSystems/Myos/processControl.htm
  5. https://www.cs.cornell.edu/courses/cs4410/2013su/slides/lecture03.pdf
  6. https://www.baeldung.com/linux/pcb
  7. https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-intro.pdf
  8. https://cics.umass.edu/~emery/classes/cmpsci691st/readings/OS/multics-overview.pdf
  9. https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf
  10. http://www.bitsavers.org/pdf/ibm/360/os/R19_Jun70/GC28-6628-5_System_Control_Blocks_Rel_19_Jun70.pdf
  11. https://multicians.org/history.html
  12. https://docs.kernel.org/scheduler/sched-design-CFS.html
  13. https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/ntos/ps/eprocess/index.htm
  14. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-1.pdf
  15. https://www.cs.umbc.edu/courses/undergraduate/421/spring03/slides/ch4.pdf
  16. https://man7.org/linux/man-pages/man1/nice.1.html
  17. https://man7.org/linux/man-pages/man7/sched.7.html
  18. https://os.ecci.ucr.ac.cr/slides/Abraham-Silberschatz-Operating-System-Concepts-10th-2018.pdf
  19. https://imphash.medium.com/windows-process-internals-a-few-concepts-to-know-before-jumping-on-memory-forensics-part-5-a-2368187685e
  20. https://man7.org/linux/man-pages/man2/getrlimit.2.html
  21. https://docs.kernel.org/accounting/taskstats.html
  22. https://courses.cs.washington.edu/courses/cse451/21sp/lectures/04-processes.pdf
  23. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
  24. https://www.cs.ucdavis.edu/~pandey/Teaching/ECS150/Lects/03a_process.pdf
  25. https://developer.ibm.com/tutorials/l-linux-process-management/
  26. http://cse.unl.edu/~witty/class/csce351/material/lecture/pdf/lecture3.pdf
  27. https://www.cs.unc.edu/~porter/courses/comp530/f16/slides/scheduling-intro.pdf
  28. https://www.cs.swarthmore.edu/~kwebb/cs45/s24/03-Process_Context_Switching_Scheduling.pdf
  29. https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched-mlfq.pdf
  30. https://www.cs.utsa.edu/~korkmaz/teaching/resources-os-grad/tk-slides/sgg/ch05-sgg-tk.pdf
  31. https://aircconline.com/csit/papers/vol14/csit142301.pdf
  32. https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/5_CPU_Scheduling.html
  33. https://www.cs.hunter.cuny.edu/~sweiss/course_materials/csci340/slides/chapter03.pdf
  34. https://www.oreilly.com/library/view/understanding-the-linux/0596005652/ch03s05.html
  35. https://lass.cs.umass.edu/~shenoy/courses/fall12/lectures/notes/Lec04_notes.pdf
  36. https://users.dimi.uniud.it/~antonio.dangelo/LabOS/2007/lessons/helper/history/earlyunix.html
  37. https://tldp.org/LDP/tlk/kernel/processes.html
  38. https://stackoverflow.com/questions/41335509/understanding-the-pid-hash-table-in-the-linux-kernel
  39. https://linux-kernel-labs.github.io/refs/heads/master/lectures/processes.html
  40. https://cs.stackexchange.com/questions/131030/confused-between-the-terms-process-and-process-control-block
  41. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/eprocess
  42. https://unix.stackexchange.com/questions/697256/has-linux-always-separated-user-and-kernel-space
  43. https://www.geeksforgeeks.org/computer-organization-architecture/what-is-memory-management-unit/
  44. https://www.kernel.org/doc/html/latest/security/credentials.html
  45. https://man7.org/linux/man-pages/man2/fork.2.html
  46. https://nvd.nist.gov/vuln/detail/CVE-2019-13272
  47. https://www.nsa.gov/portals/75/documents/resources/everyone/digital-media-center/publications/research-papers/implementing-selinux-as-linux-security-module-report.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.