On Wed, 19 Feb 2020, Daniel Vetter wrote:
> slab does this already, and I want to use this in a memory allocation
> tracker in drm for stuff that's tied to the lifetime of a drm_device,
> not the underlying struct device. Kinda like devres, but for drm.
Would be better to export it without
On Tue, 21 May 2019, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
Just putting preempt
On Wed, 1 Aug 2018, Eric Dumazet wrote:
> The idea of having a ctor() would only be a win if all the fields that
> can be initialized in the ctor are contiguous and fill an integral
> number of cache lines.
Ok. Its reducing code size and makes the object status more consistent.
Isn't that
On Wed, 1 Aug 2018, Dmitry Vyukov wrote:
> But we are trading 1 indirect call for comparable overhead removed
> from much more common path. The path that does ctors is also calling
> into page alloc, which is much more expensive.
> So ctor should be a net win on performance front, no?
ctor would
On Tue, 31 Jul 2018, Andrey Ryabinin wrote:
> Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache
> without constructor.
> I think it's nearly impossible to use that combination without having bugs.
> It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need
