Nathan Lynch wrote: > Hello Oren, > > Oren Laadan <[email protected]> writes: > >> From: Nathan Lynch <[email protected]> >> >> Support for checkpointing and restarting GPRs, FPU state, DABR, and >> Altivec state. > > ... > >> Signed-off-by: Nathan Lynch <[email protected]> > > ... > >> +/* dump the cpu state and registers of a given task */ >> +int checkpoint_write_cpu(struct ckpt_ctx *ctx, struct task_struct *t) >> +{ >> + struct ckpt_hdr_cpu *cpu_hdr; >> + int rc; >> + >> + rc = -ENOMEM; >> + cpu_hdr = ckpt_hdr_get(ctx, sizeof(*cpu_hdr), CKPT_HDR_CPU); > > This won't build (should be ckpt_hdr_get_type?). > > I didn't write this code (I used kzalloc). > > In the code I did write, I deliberately preferred the slab allocator to > the checkpoint-specific APIs. I do not see the advantage of using an > arbitrarily fixed size special allocation stack that is prone to > overflow or, worse, data corruption if someone improperly interleaves > their gets and puts. >
There is a reason I insist on it: I plan to optimize c/r app downtime by buffering data in the kernel while apps are frozen, and write-back the output after the resume execution. To do this efficiently without extra data copy you need something smarted than just kmalloc/kfree(). Since some API and implementation will be used later, it makes sense to me to enforce at API requirement already. IOW, I want the code to use ckpt_hdr_get(), ckpt_hdr_put() and ckpt_hdr_get_type(). How they are implemented, now, doesn't really matter. Your point about using kmalloc() is correct, in particular at this stage of development. So here's what I'll do: I'll keep the interface requirement, and change the implementation behind to use kmalloc/kfree(). Oren. _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
