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 Gapon _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
