<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 Mon, Jul 18, 2022 at 6:37 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de">rpalethorpe@suse.de</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">Hello Li,<br>
<br>
Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> writes:<br>
<br>
> Hi Richard,<br>
><br>
> On Tue, Jul 12, 2022 at 8:46 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.com" target="_blank">rpalethorpe@suse.com</a>> wrote:<br>
><br>
>  Kill and restart workers that take too long to read a file. The<br>
>  default being one second. A custom time can be set with the new -t<br>
>  option.<br>
><br>
>  This is to prevent a worker from blocking forever in a read. Currently<br>
>  when this happens the whole test times out and any remaining files in<br>
>  the worker's queue are not tested.<br>
><br>
>  As a side effect we can now also set the timeout very low to cause<br>
>  partial reads.<br>
><br>
> To restart workers which are blocked from reading files is a practical way.<br>
> My only concern is that restarted-worker is also slower reading on some<br>
> specific files so it will still be timed out again. Then the rest will fall into <br>
> restart cycles. Here I'd suggest loosening the worker_timeout to 3000 ms<br>
> to accommodate systems of different IO speeds.<br>
<br>
I didn't observe any issues setting the timeout very low<br>
(<100ms). Worker's remove an item from the queue before trying to read<br>
it, so they shouldn't get stuck in a restart cycle on the same file (if<br>
thats what you meant).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Ah yes, exactly.</div></div><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">
I'm not sure if this is better or worse. In my sys folder there are<br>
approx 35K files. Obviously a timeout of even 1s is far too long to read<br>
all of them if they all timeout. In fact if we set the timeout as 100ms<br>
then they would still require about 58 mins.<br></blockquote><div><br></div><div><span class="gmail_default" style="font-size:small">At the moment we </span>just give a rough value on that as nobody has lots of sample data.<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>
Of course most of them take a very short time on most systems. I guess<br>
that ideally the timeout needs to be adapted as the test runs so that<br>
all remaining files can be read. The issue with that though is that kill+wait+fork<br>
takes more time than most reads. Although that can be measured as<br>
well....<br>
<br>
This issue is quite a lot like the issues we have with fuzzy sync. I<br>
think it's maybe time to start dynamically adapting to system<br>
performance. That's probably best left to another patch series though.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, collecting sample data can help evaluate the performance.</div><div class="gmail_default" style="font-size:small">That's a practical way to make things more reliable.</div></div></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>