All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: rohitseth@google.com, CKRM-Tech <ckrm-tech@lists.sourceforge.net>,
	devel@openvz.org, linux-kernel <linux-kernel@vger.kernel.org>,
	Linux Memory Management <linux-mm@kvack.org>,
	Christoph Lameter <clameter@sgi.com>
Subject: Re: [patch00/05]: Containers(V2)- Introduction
Date: Thu, 21 Sep 2006 03:00:37 +1000	[thread overview]
Message-ID: <451173B5.1000805@yahoo.com.au> (raw)
In-Reply-To: <1158767787.3278.103.camel@taijtu>

(this time to the lists as well)

Peter Zijlstra wrote:

 > I'd much rather containterize the whole reclaim code, which should not
 > be too hard since he already adds a container pointer to struct page.


Yes, and I tend to agree with you. I probably wasn't clear, but I was
mainly talking about just the memory resource tracking part of this
patchset.

I am less willing to make a judgement about reclaim, because I don't
know very much about the workloads or the guarantees they attempt to
provide.

 > Esp. when we get some of my page reclaim abstractions merged, moving the
 > reclaim from struct zone to a container is not a lot of work. (this is
 > basically what one of the ckrm mm policies did too)


I do agree that it would be nicer to not have a completely different
scheme for doing their own page reclaim, but rather use the existing
code (*provided* that it is designed in the same, minimally intrusive
manner as the page tracking).

I can understand how it is attractive to create a new subsystem to
solve a particular problem, but once it is in the kernel it has to be
maintained regardless, so if it can be done in a way that shares more
of the current infrastructure (nicely) then that would be a better
solution.

I like that they're investigating the use of memory nodes for this.
It seems like the logical starting place.

 > I still have to reread what Rohit does for file backed pages, that gave
 > my head a spin.
 > I've been thinking a bit on that problem, and it would be possible to
 > share all address_space pages equally between attached containers, this
 > would lose some accuracy, since one container could read 10% of the file
 > and another 90%, but I don't think that is a common scenario.


Yeah, I'm not sure about that. I don't think really complex schemes
are needed... but again I might need more knowledge of their workloads
and problems.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: rohitseth@google.com, CKRM-Tech <ckrm-tech@lists.sourceforge.net>,
	devel@openvz.org, linux-kernel <linux-kernel@vger.kernel.org>,
	Linux Memory Management <linux-mm@kvack.org>,
	Christoph Lameter <clameter@sgi.com>
Subject: Re: [patch00/05]: Containers(V2)- Introduction
Date: Thu, 21 Sep 2006 03:00:37 +1000	[thread overview]
Message-ID: <451173B5.1000805@yahoo.com.au> (raw)
In-Reply-To: <1158767787.3278.103.camel@taijtu>

(this time to the lists as well)

Peter Zijlstra wrote:

 > I'd much rather containterize the whole reclaim code, which should not
 > be too hard since he already adds a container pointer to struct page.


Yes, and I tend to agree with you. I probably wasn't clear, but I was
mainly talking about just the memory resource tracking part of this
patchset.

I am less willing to make a judgement about reclaim, because I don't
know very much about the workloads or the guarantees they attempt to
provide.

 > Esp. when we get some of my page reclaim abstractions merged, moving the
 > reclaim from struct zone to a container is not a lot of work. (this is
 > basically what one of the ckrm mm policies did too)


I do agree that it would be nicer to not have a completely different
scheme for doing their own page reclaim, but rather use the existing
code (*provided* that it is designed in the same, minimally intrusive
manner as the page tracking).

I can understand how it is attractive to create a new subsystem to
solve a particular problem, but once it is in the kernel it has to be
maintained regardless, so if it can be done in a way that shares more
of the current infrastructure (nicely) then that would be a better
solution.

I like that they're investigating the use of memory nodes for this.
It seems like the logical starting place.

 > I still have to reread what Rohit does for file backed pages, that gave
 > my head a spin.
 > I've been thinking a bit on that problem, and it would be possible to
 > share all address_space pages equally between attached containers, this
 > would lose some accuracy, since one container could read 10% of the file
 > and another 90%, but I don't think that is a common scenario.


Yeah, I'm not sure about that. I don't think really complex schemes
are needed... but again I might need more knowledge of their workloads
and problems.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

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

  parent reply	other threads:[~2006-09-20 17:00 UTC|newest]

Thread overview: 150+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-20  2:16 [patch00/05]: Containers(V2)- Introduction Rohit Seth
2006-09-20  5:39 ` Nick Piggin
2006-09-20 16:26   ` Christoph Lameter
2006-09-20 16:26     ` Christoph Lameter
2006-09-20 16:56     ` Nick Piggin
2006-09-20 16:56       ` Nick Piggin
2006-09-20 17:08       ` Christoph Lameter
2006-09-20 17:08         ` Christoph Lameter
2006-09-20 17:19         ` Nick Piggin
2006-09-20 17:19           ` Nick Piggin
2006-09-20 17:30           ` Christoph Lameter
2006-09-20 17:30             ` Christoph Lameter
2006-09-20 18:03             ` Nick Piggin
2006-09-20 18:03               ` Nick Piggin
2006-09-20 17:40       ` Alan Cox
2006-09-20 17:40         ` Alan Cox
2006-09-20 16:27   ` Rohit Seth
2006-09-20 16:27     ` Rohit Seth
     [not found]   ` <1158751720.8970.67.camel@twins>
     [not found]     ` <4511626B.9000106@yahoo.com.au>
     [not found]       ` <1158767787.3278.103.camel@taijtu>
2006-09-20 17:00         ` Nick Piggin [this message]
2006-09-20 17:00           ` Nick Piggin
2006-09-20 17:23           ` [ckrm-tech] " Paul Menage
2006-09-20 17:23             ` Paul Menage
2006-09-20 17:36           ` Alan Cox
2006-09-20 17:36             ` Alan Cox
2006-09-20 17:30             ` Nick Piggin
2006-09-20 17:30               ` Nick Piggin
2006-09-20 17:50           ` Rohit Seth
2006-09-20 17:50             ` Rohit Seth
2006-09-20 17:52             ` Christoph Lameter
2006-09-20 17:52               ` Christoph Lameter
2006-09-20 18:06               ` Peter Zijlstra
2006-09-20 18:06                 ` Peter Zijlstra
2006-09-20 18:14                 ` Rohit Seth
2006-09-20 18:14                   ` Rohit Seth
2006-09-20 18:27                   ` Peter Zijlstra
2006-09-20 18:27                     ` Peter Zijlstra
2006-09-20 18:33                     ` [ckrm-tech] " Paul Menage
2006-09-20 18:33                       ` Paul Menage
2006-09-20 18:38                     ` Rohit Seth
2006-09-20 18:38                       ` Rohit Seth
2006-09-20 19:48                 ` Paul Jackson
2006-09-20 19:48                   ` Paul Jackson
2006-09-20 19:48                 ` Christoph Lameter
2006-09-20 19:48                   ` Christoph Lameter
2006-09-20 19:51                   ` [ckrm-tech] " Paul Menage
2006-09-20 19:51                     ` Paul Menage
2006-09-20 18:37             ` Peter Zijlstra
2006-09-20 18:37               ` Peter Zijlstra
2006-09-20 18:57               ` Rohit Seth
2006-09-20 18:57                 ` Rohit Seth
2006-09-20 13:06 ` [Devel] " Cedric Le Goater
2006-09-20 16:45   ` Rohit Seth
2006-09-20 16:25 ` Christoph Lameter
2006-09-20 16:44   ` Nick Piggin
2006-09-20 16:48     ` Christoph Lameter
2006-09-20 17:07       ` Nick Piggin
2006-09-20 17:12         ` Christoph Lameter
2006-09-20 22:27           ` Paul Jackson
2006-09-20 22:59             ` Christoph Lameter
2006-09-20 17:26   ` Rohit Seth
2006-09-20 17:37     ` [ckrm-tech] " Paul Menage
2006-09-20 17:38     ` Christoph Lameter
2006-09-20 17:42       ` [ckrm-tech] " Paul Menage
2006-09-20 18:07       ` Rohit Seth
2006-09-20 19:51         ` Christoph Lameter
2006-09-20 20:06         ` Paul Jackson
2006-09-20 22:58         ` Paul Jackson
2006-09-20 23:02           ` Christoph Lameter
2006-09-20 23:33             ` Rohit Seth
2006-09-20 23:36               ` Christoph Lameter
2006-09-20 23:39                 ` Rohit Seth
2006-09-20 23:51                   ` Christoph Lameter
2006-09-21  0:05                     ` Paul Jackson
2006-09-21  0:09                       ` [ckrm-tech] " Paul Menage
2006-09-20 23:26           ` Rohit Seth
2006-09-20 23:31             ` Christoph Lameter
2006-09-21  0:51               ` [Lhms-devel] " KAMEZAWA Hiroyuki
2006-09-21  1:33                 ` KAMEZAWA Hiroyuki
2006-09-21  1:36                   ` [ckrm-tech] " Paul Menage
2006-09-20 22:51     ` Paul Jackson
2006-09-20 23:01       ` Christoph Lameter
2006-09-20 23:22       ` Rohit Seth
2006-09-20 23:45         ` Paul Jackson
2006-09-20 17:34   ` Alan Cox
2006-09-20 17:15     ` Christoph Lameter
2006-09-20 17:48       ` Alan Cox
2006-09-20 17:35         ` Christoph Lameter
2006-09-20 23:29         ` Paul Jackson
2006-09-20 23:18       ` Paul Jackson
2006-09-20 17:30     ` [ckrm-tech] " Paul Menage
2006-09-20 23:37       ` Paul Jackson
2006-09-20 23:53         ` Paul Menage
2006-09-21  0:07           ` Paul Jackson
2006-09-21  0:10             ` Paul Menage
2006-09-21  0:17               ` Paul Jackson
2006-09-20 18:34   ` Chandra Seetharaman
2006-09-20 18:43     ` Paul Menage
2006-09-20 18:54       ` Chandra Seetharaman
2006-09-20 19:25         ` Paul Menage
2006-09-20 19:35           ` Chandra Seetharaman
2006-09-20 19:57             ` Paul Menage
2006-09-21  0:30               ` Chandra Seetharaman
2006-09-21  0:33                 ` Paul Jackson
2006-09-21  0:50                   ` Chandra Seetharaman
2006-09-21  0:34                 ` Paul Menage
2006-09-20 20:49           ` Paul Jackson
2006-09-20 20:51             ` Paul Menage
2006-09-20 21:04               ` Paul Jackson
     [not found]                 ` <6599ad830609201605s2fc1ccbdse31e3e60a50d56bc@mail.google.com>
2006-09-20 23:54                   ` Paul Jackson
2006-09-20 23:57                     ` Paul Menage
2006-09-21  0:09                       ` Paul Jackson
2006-09-21  1:25                   ` Chandra Seetharaman
2006-09-21  0:45             ` Chandra Seetharaman
2006-09-21  0:51               ` Paul Jackson
2006-09-20 19:55         ` Christoph Lameter
2006-09-20 20:27         ` Paul Jackson
2006-09-21 17:02           ` Srivatsa Vaddagiri
2006-09-21 19:29             ` Paul Jackson
2006-09-20 20:11       ` Paul Jackson
2006-09-20 20:17         ` Paul Menage
2006-09-20 19:52     ` Christoph Lameter
2006-09-21  0:31       ` Chandra Seetharaman
2006-09-21  0:36         ` Paul Jackson
2006-09-21  0:42           ` Paul Menage
2006-09-21  1:45             ` Chandra Seetharaman
2006-09-21  1:52               ` Paul Menage
2006-09-21 20:06                 ` Chandra Seetharaman
2006-09-21 20:10                   ` Paul Menage
2006-09-21 21:44                     ` Chandra Seetharaman
2006-09-21 22:09                       ` Paul Menage
2006-09-22  0:06                         ` Chandra Seetharaman
2006-09-22  0:13                           ` Paul Menage
2006-09-22  0:55                             ` Chandra Seetharaman
2006-09-22  0:24                           ` Paul Jackson
2006-09-22  0:57                             ` Chandra Seetharaman
2006-09-22  1:11                               ` Paul Jackson
2006-09-21 21:59                     ` Paul Jackson
2006-09-21 22:07                       ` Paul Menage
2006-09-21 22:48                         ` Paul Jackson
2006-09-20 19:09   ` Chandra Seetharaman
2006-09-27 19:50 ` Chandra Seetharaman
2006-09-27 21:28   ` Rohit Seth
2006-09-27 22:24     ` Chandra Seetharaman
2006-09-28  8:01       ` Balbir Singh
2006-09-28 18:31         ` Rohit Seth
2006-09-28 21:53           ` Balbir Singh
2006-09-29  0:22             ` Rohit Seth
2006-09-28 18:12       ` Rohit Seth
2006-09-28 20:23         ` Chandra Seetharaman
2006-09-28 21:38           ` Rohit Seth

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=451173B5.1000805@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=clameter@sgi.com \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rohitseth@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.