Allan wrote:
Rafael
Thanks for the update I will be looking to implement the changes.
Can you advise on the benefit of changing the nosteal_nsec vs rechoose_interval , my thoughts were if the rechoose interval was increased to an amount larger than the time spent migrating I would benefit with keeping cpu affinity or would you set them to the same?
I am looking at a application that has i/o latency issues where it cant handle
a 2-3ms delay which we see when we replicate the data via srdf, I was initially
thinking that the thread was being migrated between the cpus which in turn
would add another delay which I was trying to measure other than that of the
initial i/o. If the thread goes into a sleep state when the i/o is ongoing and
then awakens would the rechoose interval still be exceeded by the sleep time
causing the migration?
The rechoose_interval value is set so that a thread that sleeps for a short
period of time (< rechoose_interval ticks) will run on the same cpu it
last ran on. This is to take advantage of a possibly still warm cache on
that cpu. The migration is occuring because there is some other cpu which
has a lower priority running thread, or the maximum priority of threads
waiting for
the cpu is the lowest value. In other words, the system tries to run the
thread after it wakes up as soon as possible, first checking to see if it
is best to run it where it last ran. The only additional cost for migration
might be a cross call(?). You might try running the thread bound to
a cpu (via pbind(1) or processor_bind(2)) to see what the difference is in
performance. (Or try using processor sets).
max
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
