public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Kyle McMartin <kyle@mcmartin.ca>,
	James Morris <jmorris@namei.org>,
	Christoph Hellwig <hch@infradead.org>,
	kernel@lists.fedoraproject.org, Mimi Zohar <zohar@us.ibm.com>,
	warthog9@kernel.org, Dave Chinner <david@fromorbit.com>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Serge Hallyn <serue@us.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: ima: use of radix tree cache indexing == massive waste of memory?
Date: Mon, 18 Oct 2010 20:58:10 -0400	[thread overview]
Message-ID: <1287449890.2530.97.camel@localhost.localdomain> (raw)
In-Reply-To: <20101018181916.GB12372@elte.hu>

On Mon, 2010-10-18 at 20:19 +0200, Ingo Molnar wrote:

> I think it would be fair to argue that #2 is the thing that should be fixed first 
> and foremost - before touching any data structure details.
> 
> Because if you fix #2 then all the other items will become no-op to 99.9% of the 
> people who are affected by this bug today.

Where I stand at the end of the day:

Executive summary for the TLDNR crowd:  Before upcoming patch series IMA
wasted 4,720k of memory on my test box when not configured to do
anything.  After patches IMA wastes 120k when not configured to do
anything.

------------------------

I'm considering a system with 5000 inodes in core and 1500 inodes which
IMA thinks should be measured (if it's on).  (which just so happens to
be close to the system I've been testing on shortly after reboot)

I'm going to consider 6 cases of memory usage and will post the patches
shortly after this mail.  My cases are going to be:

Linus - IMA Enabled
Linus - IMA Disabled
Allocate iint only when needed - IMA Enabled
Allocate iint only when needed - IMA Disabled
Allocate iint + RBTREE - IMA Enabled
allocate iint + RBTREE - IMA Disabled

In each case I consider 'disabled' to be 'compiled in but you didn't
tell it to do anything.'

So for Linus:
sizeof(iint) = 312
sizeof(radix) = 632
sizeof(inode delta) = 0  (how much I grew struct inode)

Given my scenario of a stock F14ish machine where 5000 inodes in core
and 1500 are IMA relevant when enabled we end up with:

Linus - Enabled			Linus - Disabled
------------------		----------------
iint_cache = 1,560k		iint_cache = 1,560k
radix = 3,160k			radix = 3,160k
inode d = 0			inode d = 0

total = 4,720k			total = 4,720k


For Allocate iint only when needed:
sizeof(iint) = 288
sizeof(radix) = 632
sizeof(inode delta) = 24 (24 bytes from iint move to struct inode)

Allocate iint - Enabled		Alloce iint - Disabled
-----------------------		----------------------
iint_cache = 342k		iint_cache = 0
radix = 948k			radix = 0
inode d = 120k			inode d  = 120k

total = 1,410k			total = 120k


For allocate iint only when needed and use rbtrees:
sizeof(iint) = 320
sizeof(radix) = 632 (but irrelevant)
sizeof(inode delta) = 24

Allocate + RBTREE - Enabled	Allocate iint + RBTREE - Disabled
---------------------------	---------------------------------
iint_cache = 480k		iint_cache = 0
radix = 0			radix = 0
inode d = 120k			inode d = 120k

total = 600k			total = 120k

Seems like about the best we can do.  This patch series attempts to
addresses all 3 of the problems I believe we identified (we still
serialize IMA relevant inodes but not the majority of them and none when
IMA is not enabled)

IMA will continue to waste 24 bytes per inode in core even when it isn't
doing anything useful just by compiling it in.  Future work to use a
freezer could get rid of this if the complexity is worth the tradeoff.
But I don't think it's worth it tonight.

-Eric


  parent reply	other threads:[~2010-10-19  0:59 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-16  6:52 ima: use of radix tree cache indexing == massive waste of memory? Dave Chinner
2010-10-16 19:20 ` Christoph Hellwig
2010-10-16 21:10   ` H. Peter Anvin
2010-10-17  0:35     ` Dave Chinner
2010-10-17  0:54       ` J.H.
2010-10-17  2:11         ` Dave Chinner
2010-10-18 18:12           ` J.H.
2010-10-17  0:49     ` Christoph Hellwig
2010-10-17  1:09       ` Kyle McMartin
2010-10-17  1:13         ` Christoph Hellwig
2010-10-17  5:49           ` Ingo Molnar
2010-10-17  5:40       ` Ingo Molnar
2010-10-17 18:46         ` Christoph Hellwig
2010-10-18  0:49           ` James Morris
2010-10-18  6:25             ` Kyle McMartin
2010-10-18  6:36               ` Andrew Morton
2010-10-18  9:29                 ` Dave Chinner
2010-10-18 13:31                   ` Mimi Zohar
2010-10-18 20:50                     ` Ware, Ryan R
2010-10-26  7:31                       ` Pavel Machek
2010-10-18 16:03               ` Mimi Zohar
2010-10-18 19:24                 ` John Stoffel
2010-10-18 16:46               ` Ryan Ware
2010-10-18 16:48               ` Eric Paris
2010-10-18 17:10                 ` Kyle McMartin
2010-10-18 17:34                 ` Kyle McMartin
2010-10-18 17:56                 ` Linus Torvalds
2010-10-18 18:13                   ` Eric Paris
2010-10-18 18:19                     ` Ingo Molnar
2010-10-18 18:43                       ` Eric Paris
2010-10-19  0:58                       ` Eric Paris [this message]
2010-10-18 18:06                 ` H. Peter Anvin
2010-10-18 18:11                   ` Ingo Molnar
2010-10-18 18:13                     ` H. Peter Anvin
2010-10-25 13:18             ` Pavel Machek
2010-10-17  5:57   ` Mimi Zohar
2010-10-17 11:02     ` Peter Zijlstra
2010-10-17 13:12       ` Eric Paris
2010-10-17 13:59         ` Peter Zijlstra
2010-10-17 14:04           ` Peter Zijlstra
2010-10-17 14:16           ` Eric Paris
2010-10-18 11:57             ` Peter Zijlstra
2010-10-18 14:59               ` Ted Ts'o
2010-10-18 15:02                 ` Peter Zijlstra
2010-10-18 15:02                 ` Eric Paris
2010-10-17 18:52           ` Christoph Hellwig
2010-10-18 16:44             ` Ryan Ware
2010-10-18  0:07         ` Dave Chinner
2010-10-17 14:09       ` Mimi Zohar
2010-10-17 18:49     ` Christoph Hellwig
2010-10-17 19:39     ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2010-10-18 15:09 Christoph Hellwig

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=1287449890.2530.97.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jmorris@namei.org \
    --cc=kernel@lists.fedoraproject.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=serue@us.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=warthog9@kernel.org \
    --cc=zohar@us.ibm.com \
    /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