<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 6:49 PM Cyril Hrubis <<a href="mailto:chrubis@suse.cz">chrubis@suse.cz</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"><span class="gmail_default" style="font-size:small">...</span><br>
<br>
Can we add this to the tst_test structure so that test case use this as:<br>
<br>
static struct tst_test test = {<br>
...<br>
.needs_hugepages = 1,<br>
...<br>
}<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Good point.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That way it will be included in the test metadata I'm working on.<br>
<br>
<span class="gmail_default" style="font-size:small">...</span><br>
> +<br>
> + if (hpages > max_hpages) {<br>
> + tst_res(TINFO, "Request %ld hugepages failed, memory too fragmented? "<br>
> + "The max hugepage available count %ld",<br>
> + hpages, max_hpages);<br>
> + return 0;<br>
<br>
I guess that rest of the library functions returns non-zero on failure.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Sure, will reset the value for return.</div></div><div> </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>
> +<br>
> + SAFE_FILE_PRINTF("/proc/sys/vm/nr_hugepages", "%ld", hpages);<br>
> + SAFE_FILE_SCANF("/proc/sys/vm/nr_hugepages", "%d", &val);<br>
> + if (val != hpages)<br>
> + tst_brk(TBROK, "nr_hugepages = %d, but expect %ld", val, hpages);<br>
> +<br>
> + return 1;<br>
<br>
I guess that things will be more complicated than this. If there is<br>
already a pool of hugepages allocated on the machine and some are used<br>
this will utimatelly fail.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I don't think so, if they're already many huge pages being used, the free memory of the system will firstly tell us the max_hpages is not satisfy for testing, it means we have no chance to arrive here.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I rember that we changed some tests to increase the nr_hugepages if<br>
needed instead of blindly writing values there.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, but that's only fit for the situation which does not need the precise number of pages, we could take 80% of the max_hpages and do our testing in our system. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But in this function, my purpose is to request the least number of pages for the test. e.g if the .needs_hugepages is set to an expected number, we should verify strictly if the system can provide that.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also this fails to cleanup after itself, we have to restore the system<br>
after the test, which is one more reason why we need .needs_hugepages in<br>
the tst_test structure because the test library can cleanup after the<br>
test with that.<br></blockquote><div><br></div></div><div class="gmail_default" style="font-size:small">Agree, I will add the save/restore part for this.</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>