## 7 Discussion
### Limitations of This Work  
Our work on developing the simulation platform is not complete, as the simulation results show that there is still room for improvement. There are also some other weaknesses and limitations. In this section, we identify some of them.  
**I/O operations**: the implemented model involves certain simplifications compared with real-world scheduling, such as all jobs being in either the running or ready state. In reality, some processes are blocked/waiting due to ongoing I/O operations. This model may not accurately simulate scenarios where certain scheduling algorithms perform better on interactive workloads, as it does not account for processes in the blocked state.  
**No cache**: hardware employs various types of caches to enhance performance [27]. These typically include:  
* **Instruction cache**: speeds up instruction fetching.
* **Data cache**: stores and retrieves data more rapidly, often organized in L1, L2, and L3 cache layers.
* **Translation lookaside buffer**: facilitates the swift mapping of virtual addresses to physical addresses, assisting memory management.  
The model/simulation does not incorporate any of these cache types, rendering the test results somewhat unrealistic in comparison with a real operating system. The most significant impact on system performance arises from job migrations, where all accumulated caches in a given CPU are squandered upon process migration. Since the migration process is infrequent, its impact on the results is minimal.  
**Scheduling overhead**: the simulation aims to capture the overhead of frequent context switching but may deviate significantly from reality. Our approach introduces a context-switching overhead of around 5-20% depending on running time, whereas real operating systems might exhibit 1%. Furthermore, the model overlooks other complexities present in operating systems, such as memory usage variations and diverse CPU loads. The system in our simulation always aims to run at 100%, which might not align with the realistic scenarios encountered in many use cases.  
**Datasets**: it is important to note that the data used in the simulation are randomly generated and do not represent any real-world workload. Although multiple datasets were employed for comparison, using real-world workloads from high-traffic servers could have provided a more accurate assessment of the scheduling algorithms compared with randomly generated datasets.  
**Job stealing algorithm**: the job stealing process presents inherent challenges when combined with the distribution aspect. In various scenarios, a job transitioning from a local queue may find itself back in the same local queue or end up in another local queue where the CPU is already occupied. The redistribution mechanism aims to place the job in thelocal queue of an idle CPU, but this guarantee is not ensured in our case when multiple local queues have the minimum amount of jobs. It might not happen in certain instances, as the job could circulate among busy CPUs without reaching an idle one. Given sufficient time, the job is expected to reach an idle CPU eventually.  
The job stealing algorithm takes only a single job from a local queue and places it into the global queue for further distribution. In specific scenarios, a local queue \(t\) may have multiple jobs (e.g., 10) while another local queue \(q\) is at 0. The algorithm will steal only one job at a time, suggesting that the migrated job will receive more CPU time compared with the jobs remaining in the local queue \(t\).