Hi Sebastien, > That's an idea, but: > 1) It would limit the number of concurrently loaded processes, since big > tags would be slow to compare and use significant on-chip memory.
which register size is considered big? I think 8 bit would be enough - but I have no idea if this is already imposing a problem. Anyway, having a small task ID register would be better than having none. In the event the number of tasks exceeds the capacity of the task ID register, the OS can still start flushing caches. > 2) Does it bring a real gain compared to flushing the caches at each > context switch? In other words, what percentage of the cache data loaded > for one task will not get evicted before the kernel schedules that task > again? Considering a time slice is ~20ms, this looks like plenty of time > for the task execution to replace the quasi totality of the cache > contents... In practice, context switches happen far more often than that. Just consider piping a 1 MB file through a UNIX pipe, which is typically buffered with 4K. You will get 256 context switches between producer and consumer and vice versa. In general, context switches also happen a lot in the presence of I/O bound workloads. E.g., a GUI that becomes active each time an interrupt from the input-device controller occurs. If there is another CPU-bound process in the system, each PS/2 interrupt will effectively cause a context switch to the GUI. For a microkernel-based OS, the number of context switches gets even more problematic because each driver lives in a separate user process that communicates with the rest of the system via IPC messages. Each message implies (at least) one context switch. On the other hand, when the OS is using a single-address-space concept (each user program and the kernel use distinct virtual addresses) with memory protection only, there is no need for virtual memory at all (and no need for cache flushing if the cache is virtually tagged). A memory protection unit and a 1:1 virt-phys mapping would suffice. However, I would very much appreciate virtual memory, which principally enables (or at least greatly simplifies) modern OS features such as on-demand paging and dynamically loaded shared libraries. Best regards Norman _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode Twitter: www.twitter.com/milkymistvj Ideas? http://milkymist.uservoice.com
