26.09.2012 21:37, Serge Hallyn пишет:
Quoting Stanislav Kinsbursky (skinsbur...@parallels.com):
This is a cleanup patch. The assignment is redundant.
Signed-off-by: Stanislav Kinsbursky skinsbur...@parallels.com
---
ipc/msg.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff
On 09/26/2012 07:51 PM, Michal Hocko wrote:
On Tue 18-09-12 18:04:03, Glauber Costa wrote:
This patch introduces infrastructure for tracking kernel memory pages to
a given memcg. This will happen whenever the caller includes the flag
__GFP_KMEMCG flag, and the task belong to a memcg other than
On Thu 27-09-12 01:24:40, Glauber Costa wrote:
[...]
About use cases, I've already responded: my containers use case is kmem
limited. There are people like Michal that specifically asked for
user-only semantics to be preserved.
Yes, because we have many users (basically almost all) who care
Michal, Johannes, Kamezawa, what are your thoughts?
waiting! =)
Well, you guys generated a lot of discussion that one has to read
through, didn't you :P
We're quite good at that!
___
Devel mailing list
Devel@openvz.org
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level of
use_hierarchy fiasco. I'm gonna NACK on this.
As I said: all use cases I particularly care about are covered by a
global switch.
I am laying down my views because I
On 09/27/2012 04:15 PM, Michal Hocko wrote:
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level of
use_hierarchy fiasco. I'm gonna NACK on this.
As I said: all use cases I particularly care about are covered by a
global switch.
I am
On Thu 27-09-12 16:20:55, Glauber Costa wrote:
On 09/27/2012 04:15 PM, Michal Hocko wrote:
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level of
use_hierarchy fiasco. I'm gonna NACK on this.
As I said: all use cases I
On 09/27/2012 04:40 PM, Michal Hocko wrote:
On Thu 27-09-12 16:20:55, Glauber Costa wrote:
On 09/27/2012 04:15 PM, Michal Hocko wrote:
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level of
use_hierarchy fiasco. I'm gonna NACK on this.
On Thu 27-09-12 16:40:03, Glauber Costa wrote:
On 09/27/2012 04:40 PM, Michal Hocko wrote:
On Thu 27-09-12 16:20:55, Glauber Costa wrote:
On 09/27/2012 04:15 PM, Michal Hocko wrote:
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level
On Tue, Sep 18, 2012 at 06:04:02PM +0400, Glauber Costa wrote:
This flag is used to indicate to the callees that this allocation is a
kernel allocation in process context, and should be accounted to
current's memcg. It takes numerical place of the of the recently removed
__GFP_NO_KSWAPD.
On Thu 27-09-12 15:31:57, Glauber Costa wrote:
On 09/26/2012 07:51 PM, Michal Hocko wrote:
On Tue 18-09-12 18:04:03, Glauber Costa wrote:
[...]
+ *_memcg = NULL;
+ rcu_read_lock();
+ p = rcu_dereference(current-mm-owner);
+ memcg = mem_cgroup_from_task(p);
mem_cgroup_from_task
On 09/27/2012 05:34 PM, Mel Gorman wrote:
On Tue, Sep 18, 2012 at 06:04:02PM +0400, Glauber Costa wrote:
This flag is used to indicate to the callees that this allocation is a
kernel allocation in process context, and should be accounted to
current's memcg. It takes numerical place of the of
On Tue, Sep 18, 2012 at 06:04:04PM +0400, Glauber Costa wrote:
When a process tries to allocate a page with the __GFP_KMEMCG flag, the
page allocator will call the corresponding memcg functions to validate
the allocation. Tasks in the root memcg can always proceed.
To avoid adding markers to
On Tue 18-09-12 18:04:04, Glauber Costa wrote:
When a process tries to allocate a page with the __GFP_KMEMCG flag, the
page allocator will call the corresponding memcg functions to validate
the allocation. Tasks in the root memcg can always proceed.
To avoid adding markers to the page - and
On Wed, Sep 26, 2012 at 04:08:07PM -0700, Tejun Heo wrote:
Hello, Glauber.
On Thu, Sep 27, 2012 at 02:54:11AM +0400, Glauber Costa wrote:
I don't. Much has been said in the past about the problem of sharing. A
lot of the kernel objects are shared by nature, this is pretty much
Hello, Michal.
On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
Yes, because we have many users (basically almost all) who care only
about the user memory because that's what occupies the vast majority of
the memory. They usually want to isolate workload which would disrupt
the
On Thu, Sep 27, 2012 at 07:33:00AM -0700, Tejun Heo wrote:
Hello, Michal.
On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
Yes, because we have many users (basically almost all) who care only
about the user memory because that's what occupies the vast majority of
the memory.
Hello, Mel.
On Thu, Sep 27, 2012 at 03:28:22PM +0100, Mel Gorman wrote:
In addition, how is userland supposed to know which
workload is shared kmem heavy or not?
By using a bit of common sense.
An application may not be able to figure this out but the administrator
is going to be able
Hello, Mel.
On Thu, Sep 27, 2012 at 03:43:07PM +0100, Mel Gorman wrote:
I'm not too convinced. First of all, the overhead added by kmemcg
isn't big.
Really?
If kmemcg was globally accounted then every __GFP_KMEMCG allocation in
the page allocator potentially ends up down in
On Thu 27-09-12 07:33:00, Tejun Heo wrote:
Hello, Michal.
On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
Yes, because we have many users (basically almost all) who care only
about the user memory because that's what occupies the vast majority of
the memory. They usually
On 09/27/2012 06:49 PM, Tejun Heo wrote:
Hello, Mel.
On Thu, Sep 27, 2012 at 03:28:22PM +0100, Mel Gorman wrote:
In addition, how is userland supposed to know which
workload is shared kmem heavy or not?
By using a bit of common sense.
An application may not be able to figure this out
Hello,
On Thu, Sep 27, 2012 at 06:57:59PM +0400, Glauber Costa wrote:
Because we're not even trying to actually solve the problem but just
dumping it to userland. If dentry/inode usage is the only case we're
being worried about, there can be better ways to solve it or at least
we should
On Thu 27-09-12 10:46:05, Tejun Heo wrote:
[...]
The part I nacked is enabling kmemcg on a populated cgroup and then
starting accounting from then without any apparent indication that any
past allocation hasn't been considered. You end up with numbers which
nobody can't tell what they
On 09/27/2012 06:58 PM, Tejun Heo wrote:
Hello, Mel.
On Thu, Sep 27, 2012 at 03:43:07PM +0100, Mel Gorman wrote:
I'm not too convinced. First of all, the overhead added by kmemcg
isn't big.
Really?
If kmemcg was globally accounted then every __GFP_KMEMCG allocation in
the page
On 09/27/2012 09:46 PM, Tejun Heo wrote:
Hello,
On Thu, Sep 27, 2012 at 06:57:59PM +0400, Glauber Costa wrote:
Because we're not even trying to actually solve the problem but just
dumping it to userland. If dentry/inode usage is the only case we're
being worried about, there can be better
25 matches
Mail list logo
