Re: [Intel-gfx] [PATCH 01/52] mm/sl[uo]b: export __kmalloc_track(_node)_caller
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 underscores. But ok. Acked-by: Christoph Lameter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
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/off around these is not sufficient? If not and you need to add another type of critical section then would this not need to be added to the preempt counters? See include/linux/preempt.h? Looks like there are sufficient bits left to put the counter in there. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
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 enough? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
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 make it esier to review the flow and guarantee that the object always has certain fields set as required before any use by the subsystem. ctors are run once on allocation of the slab page for all objects in it. ctors are not called duiring allocation and freeing of objects from the slab page. So we could avoid the intialization of the spinlock on each object allocation which actually should be faster. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
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 to > have a constructor in kmem_cache. > > Could you guys, please, verify your code if it's really need SLAB_TYPSAFE or > constructor? > > E.g. the netlink code look extremely suspicious: > > /* >* Do not use kmem_cache_zalloc(), as this cache uses >* SLAB_TYPESAFE_BY_RCU. >*/ > ct = kmem_cache_alloc(nf_conntrack_cachep, gfp); > if (ct == NULL) > goto out; > > spin_lock_init(>lock); > > If nf_conntrack_cachep objects really used in rcu typesafe manner, than 'ct' > returned by kmem_cache_alloc might still be > in use by another cpu. So we just reinitialize spin_lock used by someone else? ct may still be read by another cpu in a RCU section but the object was freed elsewhere so no other processor may modify the object. The lock must have been released before freeing the slab object and thus the initialization of the spinlock is unnecessary if it was initialized in ctor. If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable
On Mon, 21 Aug 2017, Peter Zijlstra wrote: > > Peter, is that the latest version? > > Probably, I ran into the Infiniband code and couldn't convince anybody > to help me out :/ Its been stale for a few years now I'm afraid. What help do you need? CCing linux-rdma ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
