Re: Process timing issue

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