Hi Mpe, Thanks for looking into this patch.
Michael Ellerman <[email protected]> writes: > Vaibhav Jain <[email protected]> writes: >> While removing large number of mappings from hash page tables for >> large memory systems as soft-lockup is reported because of the time >> spent inside htap_remove_mapping() like one below: >> >> watchdog: BUG: soft lockup - CPU#8 stuck for 23s! >> <snip> >> NIP plpar_hcall+0x38/0x58 >> LR pSeries_lpar_hpte_invalidate+0x68/0xb0 >> Call Trace: >> 0x1fffffffffff000 (unreliable) >> pSeries_lpar_hpte_removebolted+0x9c/0x230 >> hash__remove_section_mapping+0xec/0x1c0 >> remove_section_mapping+0x28/0x3c >> arch_remove_memory+0xfc/0x150 >> devm_memremap_pages_release+0x180/0x2f0 >> devm_action_release+0x30/0x50 >> release_nodes+0x28c/0x300 >> device_release_driver_internal+0x16c/0x280 >> unbind_store+0x124/0x170 >> drv_attr_store+0x44/0x60 >> sysfs_kf_write+0x64/0x90 >> kernfs_fop_write+0x1b0/0x290 >> __vfs_write+0x3c/0x70 >> vfs_write+0xd4/0x270 >> ksys_write+0xdc/0x130 >> system_call+0x5c/0x70 >> >> Fix this by adding a cond_resched() to the loop in >> htap_remove_mapping() that issues hcall to remove hpte mapping. This >> should prevent the soft-lockup from being reported. > > Can/should we also/instead be using H_BLOCK_REMOVE? > > cheers Current mmp_ops implementation seems to use H_BULK_REMOVE for hugepages so for removing mappings for regular pages I am looking into adding a new mmu_op that can take a range to be unmapped and I did try implmenting a new mmu_op for this which can reduce the number of hash_pte lookups needed to invalidate this range. But that would need some more work so as a stop gap I have sent out a v2 with Christophe's suggestion to add a cond_resched() every HZ interval. -- Cheers ~ Vaibhav
