On Mon, 16 Dec 2019, Michal Hocko wrote:
I am afraid that work_struct is too large to be stuffed into the struct page array (because of the lockdep part).
Yeah, this needs to be done without touching struct page. Which is why I had done the stack allocated way in this patch, but we cannot wait for it to complete in irq, so that's out the window. Andi had suggested percpu allocated work items, but having played with the idea over the weekend, I don't see how we can prevent another page being freed on the same cpu before previous work on the same cpu is complete (cpu0 wants to free pageA, schedules the work, in the mean time cpu0 wants to free pageB and workerfn for pageA still hasn't been called).
I think that it would be just safer to make hugetlb_lock irq safe. Are there any other locks that would require the same?
It would be simpler. Any performance issues that arise would probably be only seen in microbenchmarks, assuming we want to have full irq safety. If we don't need to worry about hardirq, then even better. The subpool lock would also need to be irq safe. Thanks, Davidlohr
