On Thu, 12 Nov 2015, Sergey Senozhatsky wrote:
> > 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:
>
> chdir("/sys/kernel/slab")
> while readdir
> ...
> 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);
> }
> SLAB_ATTR_RO(slab_size);
>
> static ssize_t object_size_show(struct kmem_cache *s, char *buf)
> {
> return sprintf(buf, "%d\n", s->object_size);
> }
> SLAB_ATTR_RO(object_size);
> ...
>
> so those are sprintf("%d") of `struct kmem_cache'-s `int'
> values.
>
>
> > 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'.
>
Again, I am referring only to slabinfo as its own logical unit, it
shouldn't be based on the implementation of any slab allocator in
particular. avg_objsize has nothing to do with your patch, which is
advertised as fixing the mismatch in sign type of variables under
comparison.
There seems to be an on-going issue in this patchset that you're not
confronting: you are mixing extraneous changes into patches that are
supposed to do one thing. This already got you in trouble in the first
patch where you just threw -O2 into the Makefile randomly, and without any
mention in the commit description, and then you don't understand how to
fix the warnings that it now presents in page-types.
The warnings being shown are a result of the particular _optimization_
that your gcc version has done and your subsequent patch is only
addressing the ones that appear when you, yourself, compile. Between
different gcc versions, the optimization done by -O2 may be different and
it will warn of more or less variables that may be clobbered as a result
OF ITS OPTIMIZATION. You miss entirely that _any_ variable modified after
the setjmp() can be clobbered, most notably "off" which is the iterator
of the very loop the setjmp() appears in! Playing whack-a-mole in the
warnings you get without understanding them is the issue here.
Please, very respectfully, do not include extraneous changes into
patches, especially without mentioning them in the commit description,
when the change isn't needed or understood.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>