All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels.com>
To: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	balbir@linux.vnet.ibm.com, Suleiman Souhlal <suleiman@google.com>,
	Ying Han <yinghan@google.com>,
	linux-mm@kvack.org
Subject: Re: memcg: slab control
Date: Tue, 01 Dec 2009 13:39:31 +0300	[thread overview]
Message-ID: <4B14F263.50109@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0911301447400.7131@chino.kir.corp.google.com>

David Rientjes wrote:
> On Thu, 26 Nov 2009, Pavel Emelyanov wrote:
> 
>> I'm ready to resurrect the patches and port them for slab.
>> But before doing it we should answer one question.
>>
> 
> Do you have a pointer to your latest implementation that you proposed for 
> slab?

I believe this is the one:
https://lists.linux-foundation.org/pipermail/containers/2007-September/007481.html

>> Consider we have two kmalloc-s in a kernel code - one is
>> user-space triggerable and the other one is not. From my
>> POV we should account for the former one, but should not
>> for the latter.
>>
>> If so - how should we patch the kernel to achieve that goal?
>>
> 
> I think all slab allocations should be accounted for based on current's 
> memcg other than those done in hardirq context, annotating slab 
> allocations doesn't seem scalable.  Whether the accounting is done on a 
> task level or cgroup level isn't really a problem for us since we don't 
> move tasks amongst cgroups.  I imagine there've been previous restrictions 
> on that put into place with the memcg so this doesn't seem like a 
> slabcg-specific requirement anyway.
> 
> The problem on the freeing side is mapping the object back to the cgroup 
> that allocated it.  We'd also need to map the object to the context in 
> which it was allocated to determine whether we should decrement the 
> counter or not.  How do you propose doing that without a considerable 
> overhead in memory consumption, fastpath branch, and cache cold slabcg 
> lookups?

That's the biggest problem. Generally speaking - no other way rather than
store additional pointer. In some situations you can rely on the cgroup of
a task in which context an object is being freed, but in that case once you
move a task to another cgroup your accounting is screwed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-12-01 10:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25 23:08 memcg: slab control David Rientjes
2009-11-26  1:14 ` KAMEZAWA Hiroyuki
2009-11-26  8:50   ` Balbir Singh
2009-11-26  8:56     ` KAMEZAWA Hiroyuki
2009-11-26  9:10       ` Pavel Emelyanov
2009-11-26  9:33         ` KAMEZAWA Hiroyuki
2009-11-26  9:56           ` Pavel Emelyanov
2009-11-26 10:24             ` Suleiman Souhlal
2009-11-26 12:31               ` Pavel Emelyanov
2009-11-26 12:52                 ` Suleiman Souhlal
2009-12-01  7:40                   ` Balbir Singh
2009-11-27  7:15                 ` Ying Han
2009-11-27  9:45                   ` Pavel Emelyanov
2009-12-01  5:14                   ` KOSAKI Motohiro
2009-11-30 22:57                 ` David Rientjes
2009-12-01 10:31                   ` Pavel Emelyanov
2009-12-01 22:29                     ` David Rientjes
2009-12-01  7:36             ` Balbir Singh
2009-12-01 10:40               ` Pavel Emelyanov
2009-12-01 15:14                 ` Balbir Singh
2009-12-02 10:14                   ` Pavel Emelyanov
2009-12-02 10:19                     ` Balbir Singh
2009-12-02 10:51                       ` Pavel Emelyanov
2009-11-30 22:55         ` David Rientjes
2009-12-01 10:39           ` Pavel Emelyanov [this message]
2009-11-26 10:13     ` Suleiman Souhlal
2009-11-30  9:17       ` Balbir Singh
2009-11-30 22:45   ` David Rientjes
2009-11-26  1:17 ` KAMEZAWA Hiroyuki
2009-11-26 10:01   ` Suleiman Souhlal
2009-11-26  2:35 ` KOSAKI Motohiro
2009-11-27  7:01   ` Ying Han
2009-11-27  9:48     ` Pavel Emelyanov

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=4B14F263.50109@parallels.com \
    --to=xemul@parallels.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=suleiman@google.com \
    --cc=yinghan@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.