Hi Finn,
yes, that would be the end goal, but it might be easier for Geert to
merge the two patches (or a single one) on top of his preempt branch if
they come in the usual git format.
Cheers,
Michael
On 27/03/24 11:03, Finn Thain wrote:
On Wed, 27 Mar 2024, Michael Schmitz wrote:
thanks - I'm pretty sure tried that early on but botched it by excessive
locking (i.e., keeping preemption disabled when calling
get_zeroed_page()!).
So I don't think you do use too much locking here.
I'm running stress tests for a while now, without any trouble so far.
Need to add a few other stressors back in, and repeat all that on a
slower ARAnyM instance but I'm quite confident you found the solution.
Geert: with this data race fixed, it does appear my RFC patch is no
longer needed. Finn or I probably ought to prepare a new RFC patch to go
on top of your preemption patch. There is no commit ID to use in a
Fixes: tag for that one, correct?
I don't think we need a formal fix. I'd be content for Geert to simply
roll your free_pointer_table() changes and my get_pointer_table() changes
into his own commit. That way, bisection won't produce an unstable build.