From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Oren Laadan <orenl@cs.columbia.edu>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
xemul@parallels.com, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, hch@infradead.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
mingo@elte.hu
Subject: Re: C/R review
Date: Wed, 18 Mar 2009 09:00:08 -0700 [thread overview]
Message-ID: <1237392008.8286.149.camel@nimitz> (raw)
In-Reply-To: <49C0CAB9.3080500@cs.columbia.edu>
On Wed, 2009-03-18 at 06:19 -0400, Oren Laadan wrote:
> >> +The checkpoint image format is composed of records consisting of a
> >> +pre-header that identifies its contents, followed by a payload. (The
> >> +idea here is to enable parallel checkpointing in the future in which
> >> +multiple threads interleave data from multiple processes into a single
> >> +stream).
> >
> > I have my doubts about parallel checkpoint especially how large container
> > should be to need this and how much more complex code will it results in.
>
> Doubts about the need ? if I recall correctly IBM expressed interest in
> checkpointing containers with hundreds/thousands of processes that are
> spread among tens and hundreds of CPUs (multi-processor machine).
At the same time, I'd throw this kind of feature out the window in a
second if it meant getting a smaller or more understandable patch. It
certainly isn't needed now.
Alexey, I'm really just assuming here, but I'd guess that a normal VPS
has a memory footprint between hundreds of MB or a few GB, right? We're
also talking completely about RAM contents being moved here because all
the other data is a very small portion of the whole. Unless creating
the checkpoint is maxing out one CPU, the entire problem this is solving
has to do with I/O bandwidth and availability.
If we really have I/O bandwidth problems, we should probably solve that
at the I/O level and not the checkpoint level.
My only other concern would be on systems with really high NUMA ratios.
A parallel checkpoint there just makes sense because shipping everything
across an interconnect could get really expensive. We could move the
checkpoint process around to each node as we checkpoint its stuff, but
it would be a little silly to do a serial checkpoint on 1000 NUMA nodes
like that.
Anyway, I do think we should just concentrate on a single-stream
checkpoint for now. We have a lot of other problems to solve before we
get to 1000 node NUMA machines.
-- Dave
next prev parent reply other threads:[~2009-03-18 16:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 21:01 C/R review Alexey Dobriyan
2009-03-18 0:47 ` Serge E. Hallyn
2009-03-18 9:44 ` Oren Laadan
2009-03-18 10:19 ` Oren Laadan
2009-03-18 16:00 ` Dave Hansen [this message]
2009-03-18 17:53 ` Dave Hansen
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=1237392008.8286.149.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=orenl@cs.columbia.edu \
--cc=torvalds@linux-foundation.org \
--cc=xemul@parallels.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