Nathan Lynch wrote:
> Hello Oren,
>
> Oren Laadan <orenl@xxxxxxxxxxxxxxx> writes:
>
>> From: Nathan Lynch <ntl@xxxxxxxxx>
>>
>> Support for checkpointing and restarting GPRs, FPU state, DABR, and
>> Altivec state.
>
> ...
>
>> Signed-off-by: Nathan Lynch <ntl@xxxxxxxxx>
>
> ...
>
>> +/* 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
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
