<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 <<a href="mailto:vaibhavgupta40@gmail.com">vaibhavgupta40@gmail.com</a>> 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 <<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.com</a>> 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>
> Hello everyone,<br>
> .<br>
> I was exploring CRIU - Suggested Ideas for GSoC 2019, and have got interested in the following project:<br>
> <br>
> * 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's great!<br>
<br>
> .<br>
> 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'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>
> .<br>
> 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's documentation for alternative uses<br> import imp<br>The kernel is tainted: '12289\n'<br>Traceback (most recent call last):<br> File "zdtm.py", line 2306, in <module><br> opts['action'](opts)<br> File "zdtm.py", line 1975, in run_tests<br> launcher = Launcher(opts, len(torun))<br> File "zdtm.py", line 1671, in __init__<br> raise Exception("The kernel is tainted: %r" % self.__taint)<br>Exception: The kernel is tainted: '12289\n'</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'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'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("Foo %d\n", 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'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>