Chen, Kenneth W wrote:
You are correct. I forgot that nested_dtlb_miss doesn't actually do the check. I rather prefer not to add anything in the fast path to detect an exceedingly rare race event (only if ia64 architect screwed up so bad that made itc.d have 10,000 cycle latency and at the same time does a splendid job at job at ptc.g which completes in zero cycle along with other thousands of other instructions). In that event, as I said, it's actually better to simple purge the entry, write the dirty bit into in-memory page table entry and let the hardware page walker insert the new entry.
My first guess is: - keep the fast path as it is (we are in virtual mode) - after a nested DTLB fault, we do not return return to the fast path in physical but to the "completed" dirty bit fault handler I guess it is more efficient than to let the hardware page walker insert the new entry (we already have it in a register). I'll have to think it over. I'm not sure we can write anything after the nested DTLB fault. The next example: cpu0: cpu1: cpu2: dirty bit fault: attempts to read the PTE nested DTLB fault: walks page table back to dirty bit handler: (keeps the physical address of the PTE in r17) free_pgtables: ptc.g dirty bit fault address free the data page ptc.g PTE page address free the PTE page page_alloc: re-uses the old PTE page (still keeps the physical address of the PTE whose page has gone) ld or cmpxchg Probably, there is no way to make sure the physical address of the PTE remains valid => we have to switch back to virtual mode for the "completed" dirty bit fault handler. > Can you do some stress test experiments and let us know how many time ptc.l > was actually executed in vhpt_miss/tlb_miss/dirty/access > handler? Thanks. Well, to instrument the kernel may take some time... What stress test program do you think of? Zoltan - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |