Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Vegard Nossum]

On Wed, Jul 16, 2008 at 4:03 PM, Christoph Lameter
<cl@xxxxxxxxxxxxxxxxxxxx> wrote:
> Richard Kennedy wrote:
>
>> before
>> dentry             82136  82137    208   19    1 : tunables    0    0    0 : slabdata   4323   4323      0
>> after
>> dentry             79482  79482    208   39    2 : tunables    0    0    0 : slabdata   2038   2038      0
>
> 19 objects with an order 1 alloc and 208 byte size? Urgh. 8192/208 = 39 and not 19.
>
> Kmemcheck or something else active? We seem to be loosing 50% of our memory.

Hm, I don't think so? I thought that those 1 and 2 were not orders,
but in fact the number of pages. Which seems correct, since now you
have 4096 / 208 = 19 :-)

(His patch bumps order from 0 to 1, so the number of pages were bumped
from 1 to 2.)

Or..?


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/