On Tue, 16 Jan 2018, Matthew Wilcox wrote:
> On Tue, Jan 16, 2018 at 12:17:01PM -0600, Christopher Lameter wrote:
> > Draft patch of how the data structs could change. kmem_cache_attr is read
> > only.
>
> Looks good. Although I would add Kees' user feature:
Sure I tried to do this quickly so
On Tue, Jan 16, 2018 at 12:17:01PM -0600, Christopher Lameter wrote:
> Draft patch of how the data structs could change. kmem_cache_attr is read
> only.
Looks good. Although I would add Kees' user feature:
struct kmem_cache_attr {
char name[16];
unsigned int size;
Draft patch of how the data structs could change. kmem_cache_attr is read
only.
Index: linux/include/linux/slab.h
===
--- linux.orig/include/linux/slab.h
+++ linux/include/linux/slab.h
@@ -135,9 +135,17 @@ struct mem_cgroup;
void
On Tue, 16 Jan 2018, Matthew Wilcox wrote:
> > Sure this data is never changed. It can be const.
>
> It's changed at initialisation. Look:
>
> kmem_cache_create(const char *name, size_t size, size_t align,
> slab_flags_t flags, void (*ctor)(void *))
> s =
On Tue, Jan 16, 2018 at 10:54:27AM -0600, Christopher Lameter wrote:
> On Tue, 16 Jan 2018, Matthew Wilcox wrote:
>
> > I think that's a good thing! /proc/slabinfo really starts to get grotty
> > above 16 bytes. I'd like to chop off "_cache" from the name of every
> > single slab! If
On Tue, 16 Jan 2018, Matthew Wilcox wrote:
> I think that's a good thing! /proc/slabinfo really starts to get grotty
> above 16 bytes. I'd like to chop off "_cache" from the name of every
> single slab! If ext4_allocation_context has to become ext4_alloc_ctx,
> I don't think we're going to
On Tue, Jan 16, 2018 at 09:21:30AM -0600, Christopher Lameter wrote:
> > struct kmem_cache_attr {
> > const char name[32];
>
> Want to avoid the string reference mess that occurred in the past?
> Is that really necessary? But it would limit the size of the name.
I think that's a good thing!
On Sun, 14 Jan 2018, Matthew Wilcox wrote:
> > Hmmm... At some point we should switch kmem_cache_create to pass a struct
> > containing all the parameters. Otherwise the API will blow up with
> > additional functions.
>
> Obviously I agree with you. I'm inclined to not let that delay Kees'
>
