linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Lameter <cl@linux.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Dave Chinner <dchinner@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Alasdair G Kergon <agk@redhat.com>, Joe Thornber <ejt@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Heinz Mauelshagen <heinzm@redhat.com>,
	linux-mm <linux-mm@kvack.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
Date: Sat, 5 Sep 2015 11:09:07 +0900	[thread overview]
Message-ID: <20150905020907.GA1431@swordfish> (raw)
In-Reply-To: <CA+55aFzs78Y0LS2FJG7Mrh6KBFxVnsBGSAySoi7SpR+EmmGpLg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

On (09/04/15 07:11), Linus Torvalds wrote:
> >
> > But I went through the corresponding slabinfo (I track slabinfo too); and yes,
> > zero unused objects.
> 
> Ahh. I should have realized - the number you are actually tracking is
> meaningless. The "unused objects" thing is not really tracked well.
> 
> /proc/slabinfo ends up not showing the percpu queue state, so things
> look "used" when they are really just on the percpu queues for that
> slab.So the "unused" number you are tracking is not really meaningful,
> and the zeroes you are seeing is just a symptom of that: slabinfo
> isn't "exact" enough.
> 
> So you should probably do the statistics on something that is more
> meaningful: the actual number of pages that have been allocated (which
> would be numslabs times pages-per-slab).


Aha... Didn't know that, sorry.

Christoph Lameter wrote:
> Please use the slabinfo tool. What you see in /proc/slabinfo is generated
> for slab compatibility and may not show useful numbers.
> 

OK. I did another round of tests

 git clone git://sourceware.org/git/glibc.git
 make -j8
 package (xz)
 rm -fr glibc



>From slabinfo -T output

Slabcaches :  91      Aliases  : 118->69  Active:  65
Memory used:  60.0M   # Loss   :  13.2M   MRatio:    28%
# Objects  : 162.4K   # PartObj:  10.6K   ORatio:     6%

Per Cache    Average         Min         Max       Total
---------------------------------------------------------
#Objects        2.4K          11       19.0K      162.4K
#Slabs           108           1        1.8K        7.0K
#PartSlab         34           0        1.6K        2.2K
%PartSlab         7%          0%         86%         31%
PartObjs           6           0        4.7K       10.6K
% PartObj         3%          0%         33%          6%
Memory        923.9K        8.1K       10.2M       60.0M
Used          720.3K        8.0K        9.7M       46.8M
Loss          203.6K           0        6.1M       13.2M

Per Object   Average         Min         Max
---------------------------------------------
Memory           290           8        8.1K
User             288           8        8.1K
Loss               1           0          64


I took the
       "Memory used:  60.0M   # Loss   :  13.2M   MRatio:    28%"
line and generated 3 graphs:
-- "Memory used"	MM
-- "Loss"		LOSS
-- "MRatio"		RATION

for "slab_nomerge = 0" and "slab_nomerge = 1".

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

Attached.

Please let me know if you want to see files with the numbers
(slabinfo -T only).

	-ss

[-- Attachment #2: glibc-RATIO-merge_vs_nomerge.png --]
[-- Type: image/png, Size: 15874 bytes --]

[-- Attachment #3: glibc-LOSS-merge_vs_nomerge.png --]
[-- Type: image/png, Size: 16482 bytes --]

[-- Attachment #4: glibc-MM-merge_vs_nomerge.png --]
[-- Type: image/png, Size: 16937 bytes --]

  reply	other threads:[~2015-09-05  2:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02 23:13 Linus Torvalds
2015-09-03  0:48 ` Andrew Morton
2015-09-03  0:53   ` Mike Snitzer
2015-09-03  0:51 ` Mike Snitzer
2015-09-03  1:21   ` Linus Torvalds
2015-09-03  2:31     ` Mike Snitzer
2015-09-03  3:10       ` Christoph Lameter
2015-09-03  4:55         ` Andrew Morton
2015-09-03  6:09           ` Pekka Enberg
2015-09-03  8:53             ` Dave Chinner
2015-09-03  3:11       ` Linus Torvalds
2015-09-03  6:02     ` Dave Chinner
2015-09-03  6:13       ` Pekka Enberg
2015-09-03 10:29       ` Jesper Dangaard Brouer
2015-09-03 16:19         ` Christoph Lameter
2015-09-04  9:10           ` Jesper Dangaard Brouer
2015-09-04 14:13             ` Christoph Lameter
2015-09-04  6:35         ` Sergey Senozhatsky
2015-09-04  7:01           ` Linus Torvalds
2015-09-04  7:59             ` Sergey Senozhatsky
2015-09-04  9:56               ` Sergey Senozhatsky
2015-09-04 14:05               ` Christoph Lameter
2015-09-04 14:11               ` Linus Torvalds
2015-09-05  2:09                 ` Sergey Senozhatsky [this message]
2015-09-05 20:33                   ` Linus Torvalds
2015-09-07  8:44                     ` Sergey Senozhatsky
2015-09-08  0:22                       ` Sergey Senozhatsky
2015-09-03 15:02       ` Linus Torvalds
2015-09-04  3:26         ` Dave Chinner
2015-09-04  3:51           ` Linus Torvalds
2015-09-05  0:36             ` Dave Chinner
2015-09-07  9:30             ` Jesper Dangaard Brouer
2015-09-07 20:22               ` Linus Torvalds
2015-09-07 21:17                 ` Jesper Dangaard Brouer
2015-09-04 13:55           ` Christoph Lameter
2015-09-04 22:46             ` Dave Chinner
2015-09-05  0:25               ` Christoph Lameter
2015-09-05  1:16                 ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150905020907.GA1431@swordfish \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=brouer@redhat.com \
    --cc=cl@linux.com \
    --cc=dchinner@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=ejt@redhat.com \
    --cc=heinzm@redhat.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=mpatocka@redhat.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=samitolvanen@google.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=snitzer@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vgoyal@redhat.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox