On Thu, 17 Sep 2015, Jesper Dangaard Brouer wrote:
> What I'm proposing is keeping interrupts on, and then simply cmpxchg
> e.g 2 slab-pages out of the SLUB allocator (which the SLUB code calls
> freelist's). The bulk call now owns these freelists, and returns them
> to the caller. The API caller
On Wed, 16 Sep 2015 10:13:25 -0500 (CDT)
Christoph Lameter wrote:
> On Wed, 16 Sep 2015, Jesper Dangaard Brouer wrote:
>
> >
> > Hint, this leads up to discussing if current bulk *ALLOC* API need to
> > be changed...
> >
> > Alex and I have been working hard on practical use-case for SLAB
> > bu
On Wed, 16 Sep 2015, Jesper Dangaard Brouer wrote:
>
> Hint, this leads up to discussing if current bulk *ALLOC* API need to
> be changed...
>
> Alex and I have been working hard on practical use-case for SLAB
> bulking (mostly slUb), in the network stack. Here is a summary of
> what we have lear
Hint, this leads up to discussing if current bulk *ALLOC* API need to
be changed...
Alex and I have been working hard on practical use-case for SLAB
bulking (mostly slUb), in the network stack. Here is a summary of
what we have learned so far.
Bulk free'ing SKBs during TX completion is a big an