<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Richard, All,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 25, 2022 at 6:06 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.com" target="_blank">rpalethorpe@suse.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">Kill and restart workers that take too long to read a file. The<br>
default being 10% of max_runtime. A custom time can be set with the<br>
new -t 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. However setting it to less than the time it takes to<br>
start (fork) a new worker is treated as an error. Forking takes much<br>
longer than most reads.<br>
<br>
A number of other possible issues were fixed as well as a side effect<br>
of changing the scheduling:<br>
<br>
+ The worker queues are now filled in a<br>
  "round robin" way. Before this only happened when -r was large<br>
  enough.<br>
+ When testing is finished the main process waits on the child procs before<br>
  destroying the semaphores and worker queues.<br>
+ max_runtime is set to 100 secs. This is so that the worker timeout<br>
  is a round number.<br>
+ Files which don't implement O_NONBLOCK and may block, no longer need<br>
  to be avoided. Even if they refuse to die immediately;<br>
  although this may result in TBROK due to zombie processes.<br>
<br>
Note that with a worker timeout of 1s, 2 to 3 files will usually timeout on<br>
my workstation. With 2s, none will. In any case testing completes in<br>
under 3s for proc, sys or dev.<br>
<br>
This is much faster than many other machines. It's quite likely the<br>
worker timeout and max_runtime need to be increased on small and very<br>
large machines. This can be done manually by setting LTP_RUNTIME_MUL.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, apart from a bit of difficulty (at least for me) to comprehend the detailed</div><div class="gmail_default" style="font-size:small">behavior of this scheduler :). </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks for your improvements! Just one tiny query below.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Reviewed-by: Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>><br></div><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">
--- a/testcases/kernel/fs/read_all/read_all.c<br>
+++ b/testcases/kernel/fs/read_all/read_all.c<br>
<span class="gmail_default" style="font-size:small">...</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
+#include <signal.h><br>
 #include <sys/types.h><br>
 #include <sys/stat.h><br>
+#include <sys/wait.h><br>
 #include <lapi/fnmatch.h><br>
 #include <stdlib.h><br>
 #include <stdio.h><br>
@@ -43,7 +45,10 @@<br>
 #include <pwd.h><br>
 #include <grp.h><br>
<br>
+#include "tst_atomic.h"<br>
+#include "tst_safe_clocks.h"<br>
 #include "tst_test.h"<br>
+#include "tst_timer.h"<br>
<br>
 #define QUEUE_SIZE 16384<br>
 #define BUFFER_SIZE 1024<br>
@@ -55,11 +60,15 @@ struct queue {<br>
        int front;<br>
        int back;<br>
        char data[QUEUE_SIZE];<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I doubt whether we need to maintain a queue to store the paths.</div><div class="gmail_default" style="font-size:small">During the test it seems only one path is being pushed in the q->data[],</div><div class="gmail_default" style="font-size:small">so the rest of the space is wasted, right?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">By shrinking the QUEUE_SIZE to equal BUFFER_SIZE, the test</div><div class="gmail_default" style="font-size:small">still works normally.</div><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">
+       char popped[BUFFER_SIZE];<br>
 };<br>
<br>
 struct worker {<br>
+       int i;<br>
        pid_t pid;<br>
        struct queue *q;<br>
+       int last_seen;<br>
+       unsigned int kill_sent:1;<br>
 };<br>
<br></blockquote><div><br></div><div> </div></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>