Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 4, 2015 at 7:09 PM, Sergey Senozhatsky
<sergey.senozhatsky.work@xxxxxxxxx> wrote:
>
> Aha... Didn't know that, sorry.

Hey, I didn't react to it either. until you pointed out the oddity of
"no free slab memory" Very easy to overlook.

> ... And those are sort of interesting. I was expecting to see more
> diverged behaviours.
>
> Attached.

So I'm not sure how really conclusive these graphs are, but they are
certainly fun to look at. So I have a few reactions:

  - that 'nomerge' spike at roughly 780s is interesting. I wonder why
it does that.

 - it would be interesting to see - for example - which slabs are the
top memory users, and not _just_ the total (it could clarify the
spike, for example). That's obviously something that works much better
for the no-merge case, but could your script be changed to show (say)
the "top 5 slabs". Showing all of them would probably be too messy,
but "top 5" could be interesting.

 - assuming the times are comparable, it looks like 'merge' really is
noticeably faster. But that might just be noise too, so this may not
be real data.

 - regardless of how meaningful the graphs are, and whether they
really tell us anything, I do like the concept, and I'd love to see
people do things like this more often. Visualization to show behavior
is great.

That last point in particular means that if you scripted this and your
scripts aren't *too* ugly and not too tied to your particular setup, I
think it would perhaps not be a bad idea to encourage plots like this
by making those kinds of scripts available in the kernel tree.  That's
particularly true if you used something like the tools/testing/ktest/
scripts to run these things automatically (which can be a *big* issue
to show that something is actually stable across multiple boots, and
see the variance).

So maybe these graphs are meaningful, and maybe they aren't. But I'd
still like to see more of them ;)

                  Linus

--
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>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]