ia64 processors have a "ptc.g" instruction that will purge a TLB entry across all processors in a system. On current cpus there is a limitation that only one ptc.g instruction may be in flight at a time, so we serialize execution with code like this: spin_lock(&ptcg_lock); ... execute ptc.g spin_unlock(&ptcg_lock); The architecture allows for more than one purge at a time. So (without making any declarations about features of unreleased processors) it seemed like time to update the code to grab the maximum count from PAL, use that to initialize a semaphore, and change the code to: down(&ptcg_sem); ... execute ptc.g up(&ptcg_sem); This code lasted about a week before someone ran hackbench with parameters chosen to cause some swap activity (memory footprint ~8.5GB on an 8GB system). The machine promptly deadlocked because VM code called the tlbflush code while holding an anon_vma_lock, the semaphore happened to sleep because some other processor was also trying to do a purge, and the test was on a system where the limit was still just one ptc.g at a time, and the process got swapped. Now for the questions: 1) Is holding a spin lock a problem for any other arch when doing a TLB flush (I'm particularly thinking of those that need to use IPI shootdown for the purge)? 2) Is it feasible to rearrange the MM code so that we don't hold any locks while doing a TLB flush? Or should I implement some sort of spin_only_semaphore? -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
