<div dir="ltr"><div>Hi,<br><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 4:46 PM, Jan Stancek <span dir="ltr"><<a href="mailto:jstancek@redhat.com" target="_blank">jstancek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br>
<br>
----- Original Message -----<br>
> From: "Li Wang" <<a href="mailto:liwang@redhat.com">liwang@redhat.com</a>><br>
> To: <a href="mailto:ltp@lists.linux.it">ltp@lists.linux.it</a><br>
> Sent: Thursday, 19 November, 2015 10:34:35 AM<br>
> Subject: [LTP] [PATCH] hugetlb/hugemmap: add new testcase hugemmap06.c<br>
><br>
> +#include <time.h><br>
<br>
</div></div>Hi,<br>
<br>
wait.h and time.h appear to be unnecessary<br></blockquote><div>yes.<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">> +};<br><div><div class="h5">
> +<br>
> +#define ARSZ 125<br>
> +<br>
> +void setup(void)<br>
> +{<br>
> +     tst_require_root();<br>
> +<br>
> +     hpage_size = read_meminfo("Hugepagesize:") * 1024;<br>
> +<br>
> +     orig_hugepages = get_sys_tune("nr_hugepages");<br>
<br>
</div></div>Do we care about huge pages availability here? Or do we expect, that<br>
user running hugetlb runtest file is resposible for checking that?<br>
<br>
It's easy to imagine, that some kernels/systems won't support huge pages<br>
or they may not have enough of them. (For example with 16M pages this<br>
requires over 2GB)<br></blockquote><div> </div><div>yes, right, I'd like to add some checking here.<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><div class="h5"><br>
> +     addr = mmap(NULL, sz * hpage_size,<br>
> +                     PROT_READ | PROT_WRITE,<br>
> +                     MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,<br>
> +                     -1, 0);<br>
<br>
</div></div>How about allocating the largest area first and then mmaping smaller ones<br>
on top of it?<br>
<br>
That could prevent situation where first smallest area mmaps a gap between<br>
existing libraries/heap/etc. and then larger ones with same start overlap<br>
with those - since we write to those areas, bad things could happen.<br></blockquote><div><br></div><div>Good catch! It is very possible to hit the memory area which belong to libraries/heap...<br><br></div><div>let me try to mmap in reverse order. if it works, I will send patch V2.<br></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>
Regards,<br>
Jan<br>
<div class=""><div class="h5"><br>
<br></div></div></blockquote><div><br>thanks for reviewing.<br> </div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Regards,<br></div>Li Wang<br></div><div>Email: <a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a><br></div></div></div></div></div></div>
</div></div></div>