<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 17, 2013 at 8:57 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 07/17/2013 07:44 PM, Christopher Covington wrote:<br>
> Hi,<br>
><br>
> I'm interested in taking checkpoints of processes from fast systems like<br>
> hardware and restoring them on really slow software models for performance<br>
> analysis.<br>
<br>
</div>Great idea! I will add it on <a href="http://criu.org/Usage_scenarios" target="_blank">http://criu.org/Usage_scenarios</a> :)<br>
<div><br>
> So far I've been able to save and restore checkpoints on the<br>
> different systems using CRIU. Now I'm looking for some way to trigger the<br>
> checkpointing. One basic use case might be to take a process that runs for say<br>
> 100M instructions and take a checkpoint every 10M instructions to be restored<br>
> as 10 parallel runs of the model.<br>
><br>
> I'm thinking of trying to use performance counters to trigger such behavior.<br>
> Does perf already have support for triggering things like this?<br>
<br>
</div>I'm not 100% sure, but I've seen examples of python plugins for perf. From<br>
these examples, I believe that it's possible to write a plugin, that will run<br>
some code after noticing 100M instructions.<br></blockquote><div><br></div><div>This is definitely possible. You just need to register a signal handler and config your counter properly. Please see</div><div><br></div><div>
<a href="http://web.eece.maine.edu/~vweaver/projects/perf_events/perf_event_open.html#lbAH" target="_blank">http://web.eece.maine.edu/~vweaver/projects/perf_events/perf_event_open.html#lbAH</a><br></div><div><br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> If not, I'm<br>
> thinking of trying to work in the ability to send a signal, like stop, to the<br>
> process of interest once the specified count, such as 10M instructions, has<br>
> been reached. CRIU or a wrapper could then wait for process of interest to<br>
> stop, take the checkpoint, let the process continue, and then wait for it to<br>
> stop again or exit. Would such an approach make sense?<br>
<br>
</div>It makes perfect sense! Several things to note from my side.<br>
<br>
1. It's perfect case where the --track-mem + --prev-images-dir options should be<br>
used. It will help subsequent dumps take MUCH less time, since with them CRIU<br>
will not take full task dump, but instead will only grab what has changed since<br>
last dump.<br>
<br>
2. Current version of CRIU doesn't work with stopped tasks. We're currently<br>
developing it and this functionality will be available with v0.7 only. However,<br>
I think it's OK just to start "criu dump" command after perf trigger. The dump<br>
would work on a process that has done slightly more than 10M instructions, but<br>
that would be the same in case you send it STOP signal.<br>
<br>
> Thanks,<br>
> Christopher<br>
<br>
Thanks,<br>
Pavel<br>
<div><div>_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org" target="_blank">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
</div></div></blockquote></div><br></div></div>