lkml.org 
[lkml]   [2021]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 23/94] radix tree test suite: Add support for kmem_cache_free_bulk
Date
* Suren Baghdasaryan <surenb@google.com> [210528 13:55]:
> On Wed, Apr 28, 2021 at 8:36 AM Liam Howlett <liam.howlett@oracle.com> wrote:
> >
> > Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
> > ---
> > tools/testing/radix-tree/linux.c | 9 +++++++++
> > tools/testing/radix-tree/linux/slab.h | 1 +
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/tools/testing/radix-tree/linux.c b/tools/testing/radix-tree/linux.c
> > index 93f7de81fbe8..380bbc0a48d6 100644
> > --- a/tools/testing/radix-tree/linux.c
> > +++ b/tools/testing/radix-tree/linux.c
> > @@ -91,6 +91,15 @@ void kmem_cache_free(struct kmem_cache *cachep, void *objp)
> > pthread_mutex_unlock(&cachep->lock);
> > }
> >
> > +void kmem_cache_free_bulk(struct kmem_cache *cachep, size_t size, void **list)
> > +{
> > + if (kmalloc_verbose)
> > + printk("Bulk free %p[0-%lu]\n", list, size - 1);
>
> nit: Printing the address of the "list" is meaningless IMHO unless you
> output its value in kmem_cache_alloc_bulk, which you do not.

The address has been rather useful for my testing when combined with
how the list is created and the LSAN_OPTIONS="report_objects=1". When
this information is of interest is when a test fails, so the tree will
be dumped. Combined with the list head and the report_objects output, I
am able to deduce if there is too much in the list or too few, which
operation caused the issue, and what calculation is of interest.

Adding the alloc_bulk counterpart is not very useful because the
prediction of how many nodes are necessary is the worst-case, so the
head of the list is almost never used and the request size is already
known. Adding that print is just noise for my use case.

> I would also suggest combining the patch introducing
> kmem_cache_alloc_bulk with this one since they seem to be
> compementary.

Yes, I agree. I noticed this and fixed it in v2.

>
> > +
> > + for (int i = 0; i < size; i++)
> > + kmem_cache_free(cachep, list[i]);
> > +}
> > +
> > void *kmalloc(size_t size, gfp_t gfp)
> > {
> > void *ret;
> > diff --git a/tools/testing/radix-tree/linux/slab.h b/tools/testing/radix-tree/linux/slab.h
> > index 2958830ce4d7..53b79c15b3a2 100644
> > --- a/tools/testing/radix-tree/linux/slab.h
> > +++ b/tools/testing/radix-tree/linux/slab.h
> > @@ -24,4 +24,5 @@ struct kmem_cache *kmem_cache_create(const char *name, unsigned int size,
> > unsigned int align, unsigned int flags,
> > void (*ctor)(void *));
> >
> > +void kmem_cache_free_bulk(struct kmem_cache *cachep, size_t, void **);
> > #endif /* SLAB_H */
> > --
> > 2.30.2
> >
\
 
 \ /
  Last update: 2021-05-28 21:08    [W:0.945 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site