Messages in this thread | | | Subject | Re: [RFC][PATCH 8/8] check files for checkpointability | From | Dave Hansen <> | Date | Wed, 04 Mar 2009 15:41:41 -0800 |
| |
On Fri, 2009-02-27 at 18:57 -0800, Sukadev Bhattiprolu wrote: > Dave Hansen [dave@linux.vnet.ibm.com] wrote: > | > | Introduce a files_struct counter to indicate whether a particular > | file_struct has ever contained a file which can not be > | checkpointed. This flag is a one-way trip; once it is set, it may > | not be unset. > | > | We assume at allocation that a new files_struct is clean and may > | be checkpointed. However, as soon as it has had its files filled > | from its parent's, we check it for real in __scan_files_for_cr(). > | At that point, we mark it if it contained any uncheckpointable > | files. > > Hmm. Why not just copy ->may_checkpoint setting from parent (or old) > files_struct ? If parent is not checkpointable, then child won't be > and vice-versa - no ?
Because init does things that are uncheckpointable. If we purely inherit, we'll never be able to checkpoint.
> | +static void __scan_files_for_cr(struct files_struct *files) > | +{ > | + int i; > | + > | + for (i = 0; i < files->fdtab.max_fds; i++) { > | + struct file *f = fcheck_files(files, i); > | + if (!f) > | + continue; > | + if (cr_file_supported(f)) > | + continue; > | + files_deny_checkpointing(files); > | + } > | +} > | + > > A version of __scan_files_for_cr() for CONFIG_CHECKPOINT_RESTART=n or... > > | /* > | * Allocate a new files structure and copy contents from the > | * passed in files structure. > | @@ -303,6 +318,9 @@ struct files_struct *dup_fd(struct files > | goto out; > | > | atomic_set(&newf->count, 1); > | +#ifdef CONFIG_CHECKPOINT_RESTART > | + newf->may_checkpoint = 1; > | +#endif > | > | spin_lock_init(&newf->file_lock); > | newf->next_fd = 0; > | @@ -396,6 +414,7 @@ struct files_struct *dup_fd(struct files > | > | rcu_assign_pointer(newf->fdt, new_fdt); > | > | + __scan_files_for_cr(newf); > > ... #ifdef CONFIG_CHECKPOINT_RESTART here ?
gcc isn't quite smart enough to figure out that this is a noop. Please see my new set for a new compiler helper to solve this problem.
-- Dave
| |