RE: [PATCH] stack: introduce pile

> From: Bruce Richardson [mailto:[email protected]]
> Sent: Wednesday, 12 August 2026 18.16
> 
> On Wed, Aug 12, 2026 at 06:01:31PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:[email protected]]
> > > Sent: Wednesday, 12 August 2026 16.34
> > >
> > > On Wed, Aug 12, 2026 at 01:47:56PM +0000, Morten Brørup wrote:
> > > > Added a new high-performance lock-free "pile", using the Stack
> API.
> > > > The pile behaves roughly like a stack, but is not strictly LIFO.
> > > >
> > > > The pile is optimized for pushing/popping bulks of objects, which
> > > > it does significantly faster than the lock-free stack.
> > > >
> > > > Pushing/popping a number of objects not divisible by the compile
> time
> > > > configurable bulk size is handled gracefully, but not as fast as
> > > > complete bulks.
> > > >
> > > > Performance examples, stack_pile_perf_autotest vs.
> stack_lf_autotest:
> > > >
> > > > On a single core, pushing/popping 1 or 8 objects is similar
> speed.
> > > > On a single core, pushing/popping 32 objects is 2x faster.
> > > > On a single core, pushing/popping 512 objects is 10x faster.
> > > >
> > > > On four cores, pushing/popping 1, 8 or 32 objects is slightly
> faster.
> > > > On four cores, pushing/popping 512 objects is 4x faster.
> > > >
> > > How does it differ, or what are the benefits vs the standard stack.
> >
> > The standard stack is generally faster on single core.
> > Only pushing/popping 512 objects is slightly faster than the standard
> stack, but maybe the standard stack could be microoptimized to fix
> that.
> >
> > On four cores, it is slightly faster than the standard stack with
> multiple objects:
> >
> > stack_perf_autotest
> > Average cycles per object push/pop (bulk size: 1): 3806.65
> > Average cycles per object push/pop (bulk size: 8): 554.77
> > Average cycles per object push/pop (bulk size: 32): 144.70
> > Average cycles per object push/pop (bulk size: 512): 13.52
> >
> > stack_pile_perf_autotest
> > Average cycles per object push/pop (bulk size: 1): 4012.39
> > Average cycles per object push/pop (bulk size: 8): 459.82
> > Average cycles per object push/pop (bulk size: 32): 122.40
> > Average cycles per object push/pop (bulk size: 512): 9.60
> >
> >
> > > The
> > > LF
> > > stack I'd view as a strange edge case, since even with the standard
> > > MP/MC
> > > ring mempool driver you still have atomics on the fast-path and you
> > > will
> > > still get stalls if a thread gets context switched out in the
> middle of
> > > a
> > > mempool operation.
> >
> > Yes, the no-stall guarantee is a key benefit of the lock-free stack
> and the pile.
> >
> 
> Ok, that is good. Next question, rather than adding a whole new mempool
> driver implementation, can we use this to replace one of the existing
> stack
> implementations? Do we need to have so many mempool stack drivers
> generally?

We could consider replacing the lock-free stack implementation by the pile implementation, but the pile is not strictly LIFO, so it seems risky.

For a mempool holding mbufs, there's probably no harm in the difference.
But for a mempool holding some other object type, it could be harmful. I don't know.
IMO, not worth the risk.

Good idea, though!
I'm usually in favor of cleaning up. Just not this one. :-)