<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 11:10 AM Vaibhav Gupta &lt;<a href="mailto:vaibhavgupta40@gmail.com">vaibhavgupta40@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 9:57 PM Pavel Emelianov &lt;<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/12/19 2:14 PM, Vaibhav Gupta wrote:<br>
&gt; Hello everyone,<br>
&gt; .<br>
&gt; I was exploring CRIU - Suggested Ideas for GSoC 2019, and have got interested in the following project:<br>
&gt; <br>
&gt;   * Optimize logging engine -  <a href="https://criu.org/Google_Summer_of_Code_Ideas#Optimize_logging_engine" rel="noreferrer" target="_blank">https://criu.org/Google_Summer_of_Code_Ideas#Optimize_logging_engine</a><br>
<br>
That&#39;s great!<br>
<br>
&gt; .<br>
&gt; I am already exploring this topic and would like to discuss with mentors.<br>
<br>
Sure! Do you have questions about the gsoc process itself, or can we just proceed to the<br>
technical discussion?<br></blockquote><div>No, I don&#39;t have nay query regarding GSoC Procedures. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; .<br>
&gt; It would be great if mentors would like to suggest any specific resources, which can be help me to know more about the project.<br>
<br>
So, the doc to start with is <a href="https://criu.org/GSoC_Students_Recommendations" rel="noreferrer" target="_blank">https://criu.org/GSoC_Students_Recommendations</a>, it will<br>
let you start running criu instantly. Then glance through the sources/criu/log.c where<br>
the logging code sits.<br></blockquote></div></div></blockquote><div>I was following the above guide. when I run: <br></div><div><span style="font-family:monospace,monospace">$ sudo python zdtm.py run -t static/env00</span></div><div><span style="font-family:monospace,monospace">.<br></span></div><div>I get following error in the last:</div><div><span style="font-family:monospace,monospace">.<br></span></div><div><span style="font-family:monospace,monospace">zdtm.py:21: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module&#39;s documentation for alternative uses<br>  import imp<br>The kernel is tainted: &#39;12289\n&#39;<br>Traceback (most recent call last):<br>  File &quot;zdtm.py&quot;, line 2306, in &lt;module&gt;<br>    opts[&#39;action&#39;](opts)<br>  File &quot;zdtm.py&quot;, line 1975, in run_tests<br>    launcher = Launcher(opts, len(torun))<br>  File &quot;zdtm.py&quot;, line 1671, in __init__<br>    raise Exception(&quot;The kernel is tainted: %r&quot; % self.__taint)<br>Exception: The kernel is tainted: &#39;12289\n&#39;</span><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As far as the task itself is concerned -- once you&#39;re ready to run criu you can try to<br>
even just checkpoint some zdtm test with -v0 (make criu quiet) and -v4 (make criu print<br>
everything it wants) CLI option 1000 times and compare the time taken. You should notice<br>
that verbose logging gives you a noticeable penalty on the runtime (and thus the freeze<br>
time as well, the freeze time is reported via stats: <a href="https://criu.org/Statistics" rel="noreferrer" target="_blank">https://criu.org/Statistics</a>).<br>
<br>
So the goal is to have the best of two worlds -- have as many messages as with -v4, but<br>
at the maximum possible speed (i.e. -- like it&#39;s with -v0). Our research showed that the<br>
logging slow-down sits in sprintf() call that scans the formatting string and formats<br>
the arguments, so the first thing to do is to avoid doing this by logging binary data<br>
and providing a tool for decoding the resulting blob into text.<br>
<br>
Thus the task roughly falls into 3 sub-tasks:<br>
<br>
1. The code that keeps the binary messages around and flushes them into file<br>
2. The tool to decode the file with binary messages<br>
3. Turn existing pr_foo() calls into binary form<br>
<br>
The latter can be a routine task where one sits and fixes the pr_foo() arguments into<br>
binary versions, but we have a dream to make it smarter. Like this. Consider the simple<br>
logging code<br>
<br>
        int bar;<br>
        ...<br>
        pr_debug(&quot;Foo %d\n&quot;, bar);<br>
<br>
If order to make it binary we need to do this build-time trick:<br>
<br>
1. detect this pr_foo message<br>
2. get the format string and auto-assign an ID to it<br>
3. get the arguments and their types and generate a code looking smth like<br>
<br>
    mem = binary_log_get_buffer(size_of_all_arguments);<br>
    *((int *)mem) = /* ID of the message */; mem += sizeof(int);<br>
    *((typeof(bar) *)mem) = bar; mem += sizeof(bar);<br>
<br>
So far we haven&#39;t found good solution for it, but hopefully we will.<br></blockquote><div>Okay, I am gonna follow the steps you said, will be my first task. I will revert back once i complete this. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- Pavel<br>
</blockquote></div></div>
</blockquote></div></div></div>