Overall Kernel Module Design init When loaded, module will allocate and initialize memory, spawn threads The threads will “sieve” integer array Barrier synchronize before starting Concurrently crossing out multiples Barrier synchronize when finished Then mark an atomic completion flag When unloaded, module will report results and then clean up Print out remaining prime numbers Print out efficiency statistics Print out timing statistics De-allocate memory work exit CSE 422S – Operating Systems Organization

Arrays and Memory Management numbers (data) 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 counters (metadata) data_array current data_array + upper_bound - 1 ctr_array ctr_array + num_threads Module init() function needs to kmalloc() arrays for numbers and counters Sizes are given by module parameters (minus 1 for the numbers since they start at 2) If first allocation succeeds but second fails, must clean up correctly Module init() function spawns as many threads as were specified Each thread is given a pointer to its own “cross-out” counter (see next slide) Threads are allowed to be migrated by Linux (are not pinned to cores) Module exit() function needs to deallocate memory for arrays If initialization succeeded needs to kfree() arrays for numbers and counters Also may need to kfree() numbers array if second allocation failed (your choice) CSE 422S – Operating Systems Organization

Concurrency and Futile Work Even single threaded sieve may cross out the same number multiple times Doesn’t impact correctness Degrades performance somewhat Concurrency can make this worse Data race for non-prime elements Would have been crossed out earlier in a single-threaded implementation Thread’s entire “job” will duplicate work done by other threads’ jobs In this lab you’ll evaluate this effect, rather than trying to “fix” it Each thread will count its cross-outs Cross-outs in excess of the number of non-primes in the array are futile Offers a good measure of efficiency Will also measure completion times, since parallelism may help reduce them 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 CSE 422S – Operating Systems Organization

CSE 422S – Operating Systems Organization Lab Write-up As you work, again record your observations It’s a good idea to read the entire assignment, and to plan and design a bit before starting to work on it It’s also a good idea to develop and test incrementally Write a cohesive report that analyzes, integrates, and offers explanations for what you observed Run different combinations of upper bounds, #s of threads Think (and write) about what trends emerge initially Run additional experiments as needed to confirm trends CSE 422S – Operating Systems Organization