<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 Wed, Sep 22, 2021 at 4:21 PM Cyril Hrubis <<a href="mailto:chrubis@suse.cz" target="_blank">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">Hi!<br>
> > This change appears seems to be causing fallocate05 test to reliably<br>
> > trigger OOM (out of memory) on my test machine, which has only 256MB<br>
> > RAM.<br>
> ><br>
> <br>
> Thanks for reporting the failure. We purposely increase the size of<br>
> fallocate<br>
> to reduce interference from metadata changing. But not clear how much<br>
> size should be a proper value for a small system.<br>
> <br>
> Can you try with decrease the number of FALLOCATE_BLOCKS?<br>
> <br>
> i.e.<br>
> <br>
> #define FALLOCATE_BLOCKS 64<br>
> #define DEALLOCATE_BLOCKS 16<br>
> <br>
> Or, what about other multiple sizes, test result?<br>
<br>
Looking at the test I do not think there is a reason to allocate more<br>
than a two or four blocks for the buffer. We just need to write() to the<br>
fallocated area in a loop one block at a time until it's full. I do not<br>
think that it's a good idea to pass ~100MB buffer to a single write()<br>
and expect it to succeed anyways.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Sounds practical.</div><br></div><div><div class="gmail_default" style="font-size:small">Btw, If we don't create such a larger buffer area, then we have to</div><div class="gmail_default" style="font-size:small">count the loop times must as equal to bufsize/blocksize. Otherwise, </div></div><div class="gmail_default" style="font-size:small">we can't guarantee the test behavior is correct.</div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>