On Wed, Apr 10, 2024 at 11:00 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > > On 10/04/2024 07:45, Michael Paquier wrote: > > On Tue, Apr 09, 2024 at 09:16:53PM -0700, Jeff Davis wrote: > >> On Wed, 2024-04-10 at 12:13 +0900, Michael Paquier wrote: > >>> Wouldn't the best way forward be to revert > >>> 5bec1d6bc5e3 and revisit the whole in v18? > >> > >> Also consider commits b840508644 and bcb14f4abc. > > > > Indeed. These are also linked. > > I don't feel the urge to revert this: > > - It's not broken as such, we're just discussing better ways to > implement it. We could also do nothing, and revisit this in v18. The > only must-fix issue is some compiler warnings IIUC. > > - It's a pretty localized change in reorderbuffer.c, so it's not in the > way of other patches or reverts. Nothing else depends on the binaryheap > changes yet either. > > - It seems straightforward to repeat the performance tests with whatever > alternative implementations we want to consider. > > My #1 choice would be to write a patch to switch the pairing heap, > performance test that, and revert the binary heap changes. >
+1. -- With Regards, Amit Kapila.