Re: [PATCH 3/3] tools/vm/slabinfo: update struct slabinfo members' types
From: Sergey Senozhatsky
Date: Thu Nov 12 2015 - 01:16:11 EST
On (11/11/15 21:07), David Rientjes wrote:
> > > > /* Object size */
> > > > - unsigned long long min_objsize = max, max_objsize = 0, avg_objsize;
> > > > + unsigned int min_objsize = UINT_MAX, max_objsize = 0, avg_objsize;
> > > >
> > > > /* Number of partial slabs in a slabcache */
> > > > unsigned long long min_partial = max, max_partial = 0,
> > >
> > > avg_objsize should not be unsigned int.
> > Hm. the assumption is that `avg_objsize' cannot be larger
> > than `max_objsize', which is
> > `int object_size;' in `struct kmem_cache' from slab_def.h
> > and
> > `unsigned int object_size;' in `struct kmem_cache' from slab.h.
> > avg_objsize = total_used / total_objects;
I'm not sure I clearly understand the problems you're pointing
> This has nothing to do with object_size in the kernel.
what we have in slabinfo as slab_size(), ->object_size, etc.
comming from slub's sysfs attrs:
slab->object_size = get_obj("object_size");
slab->slab_size = get_obj("slab_size");
and attr show handlers are:
static ssize_t slab_size_show(struct kmem_cache *s, char *buf)
return sprintf(buf, "%d\n", s->size);
static ssize_t object_size_show(struct kmem_cache *s, char *buf)
return sprintf(buf, "%d\n", s->object_size);
so those are sprintf("%d") of `struct kmem_cache'-s `int'
> total_used and total_objects are unsigned long long.
yes, that's correct.
but `total_used / total_objects' cannot be larger that the size
of the largest object, which is represented in the kernel and
returned to user space as `int'. it must fit into `unsigned int'.
> If you need to convert max_objsize to be unsigned long long as
> well, that would be better.
... in case if someday `struct kmem_cache' will be updated to keep
`unsigned long' sized objects and sysfs attrs will do sprintf("%lu")?
IOW, if slabs will keep objects bigger that 4gig?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/