on 24/02/2011 16:18 Jerome Flesch said the following: > Thanks for your explanations. It helped greatly. Using ktrdump and schedgraph.py > and after modifying our test program to set and unset automatically > debug.ktr.mask, I've been able to get useful information. > > First, It made me realize that task switching, with default settings and 2 active > processes, only occurs each 100ms. Knowing that, expecting a latency time around > 100ms was kind of silly :) > > Next, it seems most of the latency pikes are due to a process starting or waking > up. For instance, it usually happens when the openssl speed test is started ( > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_start.png > ) or when pagedaemon wakes up (I forgot to disable the swap and my test program > used too much memory to store the result values ...). I'm not sure why, but when > we start openssl, it is often allowed to run for >= 300ms, even with our test > program set to real time priority. My intuition is that, at first, it's considered > as an interactive process, until the scheduler realizes it's not. But then, does > anyone know why it would take more than 300ms for the scheduler to realize that ? > > Anyway, by setting kern.sched.interact=5 (so openssl isn't considered as an > interactive process), kern.sched.slice=3 (to get an high enough scheduling > resolution), and our program to real-time priority, we got rid of both problems. > I'm just a little bit worried about kern.sched.slice=3. Is there any known side > effect when reducing slices size ? > > Also, another issue remain: We were hoping to keep our program with a normal > priority. However when we set our test program to a normal priority (but still an > higher priority than openssl), both get 50% of the CPU (I guess this is to be > expected), and from time to time we have a "hiccup" in the scheduling: > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.png . Is > there any way to avoid them ? In other words, is it possible to make sure that the > low priority process never gets more CPU time than the high priority one ? The problems that you describe here sound very much like the issues that John Baldwin has been trying to solve a short while ago. My recollection is that he committed some improvements for real time priority processes. Perhaps he'll have some additional insights based on his observations and testing. -- Andriy GaponReceived on Thu Feb 24 2011 - 16:34:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC