From: Oren Laadan <orenl@cs.columbia.edu>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: dave@linux.vnet.ibm.com, containers@lists.linux-foundation.org,
jeremy@goop.org, linux-kernel@vger.kernel.org, arnd@arndb.de
Subject: Re: [RFC v5][PATCH 7/8] Infrastructure for shared objects
Date: Tue, 16 Sep 2008 17:36:45 -0400 [thread overview]
Message-ID: <48D026ED.3080109@cs.columbia.edu> (raw)
In-Reply-To: <20080916205459.GA7644@us.ibm.com>
Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl@cs.columbia.edu):
>> Infrastructure to handle objects that may be shared and referenced by
>> multiple tasks or other objects, e..g open files, memory address space
>> etc.
>>
>> The state of shared objects is saved once. On the first encounter, the
>> state is dumped and the object is assigned a unique identifier (objref)
>> and also stored in a hash table (indexed by its physical kenrel address).
>> >From then on the object will be found in the hash and only its identifier
>> is saved.
>>
>> On restart the identifier is looked up in the hash table; if not found
>> then the state is read, the object is created, and added to the hash
>> table (this time indexed by its identifier). Otherwise, the object in
>> the hash table is used.
>>
>> Signed-off-by: Oren Laadan <orenl@cs.columbia.edu>
>
> Acked-by: Serge Hallyn <serue@us.ibm.com>
>
> Thanks, Oren, I actually think this is quite nice and readable.
>
> Though three questions below. First one is, since you've mentioned
> having multiple threads doing checkpoint, won't you need some locking?
yes.
> I assume that's coming in later patches if/when needed?
yes.
[...]
>> +++ b/checkpoint/objhash.c
>> @@ -0,0 +1,237 @@
>> +/*
>> + * Checkpoint-restart - object hash infrastructure to manage shared objects
>> + *
>> + * Copyright (C) 2008 Oren Laadan
>> + *
>> + * This file is subject to the terms and conditions of the GNU General Public
>> + * License. See the file COPYING in the main directory of the Linux
>> + * distribution for more details.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/file.h>
>> +#include <linux/hash.h>
>> +#include <linux/checkpoint.h>
>> +
>> +struct cr_objref {
>> + int objref;
>> + void *ptr;
>> + unsigned short type;
>
> What is the point of the 'type'?
>
> By that I mean: is it meant to catch bugs in the implementation, or bad
> checkpoint images?
The hash table is maintained in the kernel during checkpoint/restart,
adding shared objects to the hash table when they are first seen. An
object can be a 'struct file', 'struct mm_struct', etc.
When an object is added, it's reference count is incremented to ensure
that the pointer is still valid for as long as it's in the hash table.
Similarly, when we remove an object from the hash, we need to decrement
the reference count. This is done in cr_obj_ref_grab(), cr_obj_ref_drop().
There are different functions to inc/dec the reference count of objects
of different types. '->type' keeps track of the type of the object, so
we know which function to call. (At this point, we only track shared
'struct file' so it isn't that clear from the code).
>
>> + unsigned short flags;
>> + struct hlist_node hash;
>> +};
>> +
>> +struct cr_objhash {
>> + struct hlist_head *head;
>> + int objref_index;
>
> What exactly will objref_index be used for? I don't see any real
> usage here or in your later patches.
>
'objref_index' is a counter used to assign unique identifiers (objref)
to objects as they are added to the hash table. It is incremented with
every object that joins the hash table (and the old value is used as
the objref of that object). It is used in cr_obj_new().
>> +};
>> +
>> +#define CR_OBJHASH_NBITS 10
>> +#define CR_OBJHASH_TOTAL (1UL << CR_OBJHASH_NBITS)
>> +
>> +static void cr_obj_ref_drop(struct cr_objref *obj)
>> +{
>> + switch (obj->type) {
>> + case CR_OBJ_FILE:
>> + fput((struct file *) obj->ptr);
>> + break;
>> + default:
>> + BUG();
>> + }
>> +}
>> +
>> +static void cr_obj_ref_grab(struct cr_objref *obj)
>> +{
>> + switch (obj->type) {
>> + case CR_OBJ_FILE:
>> + get_file((struct file *) obj->ptr);
>> + break;
>> + default:
>> + BUG();
>> + }
>> +}
>> +
[...]
>> +static struct cr_objref *cr_obj_new(struct cr_ctx *ctx, void *ptr, int objref,
>> + unsigned short type, unsigned short flags)
>> +{
>> + struct cr_objref *obj;
>> +
>> + obj = kmalloc(sizeof(*obj), GFP_KERNEL);
>> + if (obj) {
>> + int i;
>> +
>> + obj->ptr = ptr;
>> + obj->type = type;
>> + obj->flags = flags;
>> +
>> + if (objref) {
>> + /* use 'objref' to index (restart) */
>> + obj->objref = objref;
>> + i = hash_ptr((void *) objref, CR_OBJHASH_NBITS);
>> + } else {
>> + /* use 'ptr' to index, assign objref (checkpoint) */
>> + obj->objref = ctx->objhash->objref_index++;;
>> + i = hash_ptr(ptr, CR_OBJHASH_NBITS);
>> + }
>> +
>> + hlist_add_head(&obj->hash, &ctx->objhash->head[i]);
>> + cr_obj_ref_grab(obj);
>> + }
>> + return obj;
>> +}
[...]
Oren.
next prev parent reply other threads:[~2008-09-16 21:39 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-13 23:05 [RFC v5][PATCH 0/9] Kernel based checkpoint/restart Oren Laadan
2008-09-13 23:05 ` [RFC v5][PATCH 1/8] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-09-15 20:28 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 2/8] General infrastructure for checkpoint restart Oren Laadan
2008-09-15 17:54 ` Dave Hansen
2008-09-15 17:59 ` Dave Hansen
2008-09-15 18:00 ` Dave Hansen
2008-09-15 18:02 ` Dave Hansen
2008-09-15 18:52 ` Oren Laadan
2008-09-15 19:13 ` Dave Hansen
2008-09-16 12:27 ` Bastian Blank
2008-09-15 21:15 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 3/8] x86 support for checkpoint/restart Oren Laadan
2008-09-15 21:31 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 4/8] Dump memory address space Oren Laadan
2008-09-17 6:48 ` MinChan Kim
2008-09-13 23:06 ` [RFC v5][PATCH 5/8] Restore " Oren Laadan
2008-09-15 19:14 ` Dave Hansen
2008-09-13 23:06 ` [RFC v5][PATCH 6/8] Checkpoint/restart: initial documentation Oren Laadan
2008-09-15 20:26 ` Serge E. Hallyn
2008-09-17 6:23 ` MinChan Kim
2008-09-13 23:06 ` [RFC v5][PATCH 7/8] Infrastructure for shared objects Oren Laadan
2008-09-16 16:48 ` Dave Hansen
2008-09-17 7:31 ` MinChan Kim
2008-09-16 20:54 ` Serge E. Hallyn
2008-09-16 21:36 ` Oren Laadan [this message]
2008-09-16 22:09 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 8/8] Dump open file descriptors Oren Laadan
2008-09-14 9:51 ` Bastian Blank
2008-09-14 15:40 ` Oren Laadan
2008-09-16 23:03 ` Serge E. Hallyn
2008-09-22 15:31 ` Dave Hansen
2008-09-16 15:54 ` Dave Hansen
2008-09-16 16:55 ` Dave Hansen
2008-09-13 23:06 ` [RFC v5][PATCH 9/9] Restore open file descriprtors Oren Laadan
2008-09-16 23:08 ` Serge E. Hallyn
2008-09-17 0:11 ` Oren Laadan
2008-09-17 4:56 ` Serge E. Hallyn
2008-09-22 16:02 ` Dave Hansen
2008-09-13 23:22 ` Oren Laadan
2008-09-17 14:16 ` [RFC v5][PATCH 0/9] Kernel based checkpoint/restart Serge E. Hallyn
2008-10-08 9:59 ` Oren Laadan
2008-09-24 21:42 ` Serge E. Hallyn
2008-09-25 12:58 ` Cedric Le Goater
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=48D026ED.3080109@cs.columbia.edu \
--to=orenl@cs.columbia.edu \
--cc=arnd@arndb.de \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.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