All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rohit Seth <rohitseth@google.com>
To: Andi Kleen <ak@suse.de>
Cc: CKRM-Tech <ckrm-tech@lists.sourceforge.net>,
	devel@openvz.org, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch02/05]: Containers(V2)- Generic Linux kernel changes
Date: Wed, 20 Sep 2006 09:44:29 -0700	[thread overview]
Message-ID: <1158770670.8574.26.camel@galaxy.corp.google.com> (raw)
In-Reply-To: <p7364fikcbe.fsf@verdi.suse.de>

On Wed, 2006-09-20 at 13:27 +0200, Andi Kleen wrote:
> Rohit Seth <rohitseth@google.com> writes:
> >  					 */
> > +#ifdef CONFIG_CONTAINERS
> > +	struct container_struct *ctn; /* Pointer to container, may be NULL */
> > +#endif
> 
> I still don't think it's a good idea to add a pointer to struct page for this.

I thought last time you supported adding a pointer to struct page (when
you mentioned next gen slab will also consume page->mapping).  May be I
missed your point.

> This means any kernel that enables the config would need to carry this significant
> overhead, no matter if containers are used to not.
> 
Sure this is non-zero overhead but I think this is the logical place to
track the memory.

> Better would be to store them in some other data structure that is only
> allocated on demand or figure out a way to store them in the sometimes
> not all used fields in struct page.
> 

which one...I think the fields in page structure are already getting
doubly used. 

> BTW your patchkit seems to be also in wrong order in that when 02 is applied
> it won't compile.

Not sure if I understood that.  I've myself tested these patches on
2.6.18-rc6-mm2 kernel and they apply just fine.  Are you just trying to
apply 02....if so then that wouldn't suffice.

-rohit


  reply	other threads:[~2006-09-20 16:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-20  2:18 [patch02/05]: Containers(V2)- Generic Linux kernel changes Rohit Seth
2006-09-20 11:27 ` Andi Kleen
2006-09-20 16:44   ` Rohit Seth [this message]
2006-09-20 18:14     ` Andi Kleen
2006-09-20 18:19       ` Rohit Seth
2006-09-20 18:32         ` Andi Kleen
2006-09-21  0:23       ` Christoph Lameter
2006-09-21  0:37         ` Rohit Seth
2006-09-21  0:41           ` Christoph Lameter
2006-09-21  0:53             ` Rohit Seth
2006-09-21  1:33         ` [ckrm-tech] " Chandra Seetharaman
2006-09-21 22:29           ` 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=1158770670.8574.26.camel@galaxy.corp.google.com \
    --to=rohitseth@google.com \
    --cc=ak@suse.de \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.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 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.