Re: [External Mail] [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2)

2025-01-05 Thread Hyeonggon Yoo
(-) Sorry for the late reply, but better late than never... FWIW, Acked-by: Hyeonggon Yoo Tested-by: Hyeonggon Yoo Thanks for all the efforts! By the way, any future plans how to take advantage of internal slab state? -- Hyeonggon

Re: [PATCH RFC 6/6] mm, slub: sheaf prefilling for guaranteed allocations

2024-11-18 Thread Hyeonggon Yoo
On Mon, Nov 18, 2024 at 11:26 PM Vlastimil Babka wrote: > > On 11/18/24 14:13, Hyeonggon Yoo wrote: > > On Wed, Nov 13, 2024 at 1:39 AM Vlastimil Babka wrote: > >> + > >> +/* > >> + * Allocate from a sheaf obtained by kmem_cache_prefill_sheaf() > >

Re: [PATCH RFC 6/6] mm, slub: sheaf prefilling for guaranteed allocations

2024-11-18 Thread Hyeonggon Yoo
On Wed, Nov 13, 2024 at 1:39 AM Vlastimil Babka wrote: > > Add three functions for efficient guaranteed allocations in a critical > section (that cannot sleep) when the exact number of allocations is not > known beforehand, but an upper limit can be calculated. > > kmem_cache_prefill_sheaf() retur

Re: [PATCH v2 7/7] kunit, slub: add test_kfree_rcu() and test_leak_destroy()

2024-09-25 Thread Hyeonggon Yoo
On Sun, Sep 22, 2024 at 11:13 PM Guenter Roeck wrote: > > On 9/21/24 23:16, Hyeonggon Yoo wrote: > > On Sun, Sep 22, 2024 at 6:25 AM Vlastimil Babka wrote: > >> > >> On 9/21/24 23:08, Guenter Roeck wrote: > >>> On 9/21/24 13:40, Vlastimil Babka wrote: &g

Re: [PATCH v2 7/7] kunit, slub: add test_kfree_rcu() and test_leak_destroy()

2024-09-21 Thread Hyeonggon Yoo
On Sun, Sep 22, 2024 at 6:25 AM Vlastimil Babka wrote: > > On 9/21/24 23:08, Guenter Roeck wrote: > > On 9/21/24 13:40, Vlastimil Babka wrote: > >> +CC kunit folks > >> > >> On 9/20/24 15:35, Guenter Roeck wrote: > >>> Hi, > >> > >> Hi, > >> > >>> On Wed, Aug 07, 2024 at 12:31:20PM +0200, Vlastimi

Re: [PATCH v2 7/7] kunit, slub: add test_kfree_rcu() and test_leak_destroy()

2024-09-14 Thread Hyeonggon Yoo
On Wed, Aug 7, 2024 at 7:31 PM Vlastimil Babka wrote: > > Add a test that will create cache, allocate one object, kfree_rcu() it > and attempt to destroy it. As long as the usage of kvfree_rcu_barrier() > in kmem_cache_destroy() works correctly, there should be no warnings in > dmesg and the test