Re: [PATCH v2] mm/hugetlb: defer free_huge_page() to a workqueue

[Davidlohr Bueso]

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