Re: [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Dave Hansen
Date: Friday, August 22, 2008 - 1:01 pm

On Wed, 2008-08-20 at 23:04 -0400, Oren Laadan wrote:

These all need to be fixed up to Linux style:

	ret = = cr_kwrite(ctx, h, sizeof(*h)));
	if (ret < 0)
		...;

You might want to try checkpatch.pl on these.  It is pretty good at
finding this stuff.


We at least neex EXTRAVERSION in there if we're going to even pretend
this is useful, right?  is this redundant with utsname() below?


alloc/delloc is not a bad thing. :)  I think at least a few of these
should be moved over to stack or kmalloc()/kfree().


Can a container only have one vfsroot?


enum?


What happened to include/linux/magic.h?


TASK_COMM_LEN might be subject to changing.  Can it be part of the
user<->kernel ABI?

...

I replaced all of the uses of these with kmalloc()/kfree() and stack
allocations.  I'm really not sure what these buy us since our allocators
are already so fast.  tbuf, especially, worries me if it gets used in
any kind of nested manner we're going to get some really fun bugs.


That ( ? : ) needs to get broken out so it is easier to read.  This
function is already nice and tight as it is, so saving a line or two
doesn't really do any good. 


How about just making cr_read_obj_type() stop returning positive values?
Is it ever valid for it to return >0?


If we're not going to use the cksum, can it just be pulled out for now?


Well, if TASK_COMM_LEN changed, then the size of the structure changed,
and the ABI changed.  Uh oh.



First of all, the unlikely() needs to die.  This isn't
performance-critical code, and I don't see any justification for why it
is needed.

Also, errors like -EAGAIN are just fine and normal to come back from a
write to a file.  We shoudn't be erroring out on them.  (Note that this
is something that userspace would be handling by itself if we were doing
this in userspace.)


Any particular reason you're using __get_free_pages() here?  kmalloc()
would save you a cast, and having to deal with keeping "order" vs. a
plain size.  Also, why don't you just stick tbuf and hbuf's allocation
into the ctx structure itself for now?  It'll save some of the error
paths.  Yeah, it might become an order 2 or 3 allocation, but that
should be OK.  We're not in interrupt context or anything.


Should we just combine most of these two functions?  If we passed a fd
into cr_ctx_alloc(), it could do the fget/put_light() bits, and we
wouldn't need the code in both sys_checkpoint() and sys_restart().

-- Dave

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC v2][PATCH 1/9] kernel based checkpoint-restart, Oren Laadan, (Wed Aug 20, 7:58 pm)
[RFC v2][PATCH 3/9] x86 support for checkpoint/restart, Oren Laadan, (Wed Aug 20, 8:04 pm)
[RFC v2][PATCH 4/9] Memory management - dump state, Oren Laadan, (Wed Aug 20, 8:05 pm)
[RFC v2][PATCH 5/9] Memory managemnet - restore state, Oren Laadan, (Wed Aug 20, 8:05 pm)
[RFC v2][PATCH 7/9] Infrastructure for shared objects, Oren Laadan, (Wed Aug 20, 8:06 pm)
[RFC v2][PATCH 8/9] File descriprtors - dump state, Oren Laadan, (Wed Aug 20, 8:07 pm)
[RFC v2][PATCH 9/9] File descriprtors (restore), Oren Laadan, (Wed Aug 20, 8:07 pm)
Re: [RFC v2][PATCH 1/9] kernel based checkpoint-restart, Oren Laadan, (Wed Aug 20, 10:15 pm)
Re: [RFC v2][PATCH 9/9] File descriprtors (restore), Oren Laadan, (Wed Aug 20, 10:26 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Ingo Molnar, (Thu Aug 21, 12:30 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Justin P. Mattock, (Thu Aug 21, 1:01 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Louis Rilling, (Thu Aug 21, 2:53 am)
Re: [RFC v2][PATCH 5/9] Memory managemnet - restore state, Louis Rilling, (Thu Aug 21, 3:07 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Balbir Singh, (Thu Aug 21, 3:28 am)
Re: [RFC v2][PATCH 7/9] Infrastructure for shared objects, Louis Rilling, (Thu Aug 21, 3:40 am)
Re: [RFC v2][PATCH 8/9] File descriprtors - dump state, Louis Rilling, (Thu Aug 21, 4:06 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Ingo Molnar, (Thu Aug 21, 4:59 am)
Re: [RFC v2][PATCH 2/9] General infrastructure for checkpo ..., Dave Hansen, (Fri Aug 22, 1:01 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Dave Hansen, (Fri Aug 22, 1:37 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Oren Laadan, (Fri Aug 22, 2:21 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Oren Laadan, (Sat Aug 23, 10:40 pm)
Re: [RFC v2][PATCH 8/9] File descriprtors - dump state, Oren Laadan, (Sun Aug 24, 8:28 pm)
Re: [RFC v2][PATCH 8/9] File descriprtors - dump state, Louis Rilling, (Mon Aug 25, 3:30 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Dave Hansen, (Tue Aug 26, 9:33 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Oren Laadan, (Tue Aug 26, 5:14 pm)
Re: [RFC v2][PATCH 7/9] Infrastructure for shared objects, Louis Rilling, (Wed Aug 27, 1:26 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Dave Hansen, (Wed Aug 27, 8:41 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Louis Rilling, (Wed Aug 27, 8:57 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Dave Hansen, (Wed Aug 27, 9:12 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Jeremy Fitzhardinge, (Wed Aug 27, 9:19 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Serge E. Hallyn, (Wed Aug 27, 1:34 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Dave Hansen, (Wed Aug 27, 1:38 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Serge E. Hallyn, (Wed Aug 27, 1:48 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Dave Hansen, (Wed Aug 27, 1:56 pm)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Oren Laadan, (Sun Aug 31, 12:16 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Cedric Le Goater, (Sun Aug 31, 10:34 am)
Re: [RFC v2][PATCH 4/9] Memory management - dump state, Serge E. Hallyn, (Tue Sep 2, 8:32 am)