[Devel] Re: [RFC v14][PATCH 31/54] powerpc: checkpoint/restart implementation

[Nathan Lynch]

Oren Laadan <orenl at cs.columbia.edu> writes:
> Nathan Lynch wrote:
>> 
>> Oren Laadan <orenl at cs.columbia.edu> writes:
>>> +/* 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().

That sounds reasonable to me, thanks.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers