m...@bruningsystems.com wrote:
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.
That's correct, but these variables are used in different situations for
similar purposes. rechoose_interval is used to help decide on which
CPU's runq a thread should be placed. nosteal_nsec is used when an idle
CPU checks if there's any work that can be stolen from another CPU's runq.
This means in part that a thread that was kept on a runq to preserve its
cache warm might still get stolen by another CPU if possible. But the
code that does the stealing checks for a number of different things, one
of which is whether the stealing CPU and the current target CPU share
cache. If they don't share, then nosteal_nsec is used to see if the
target thread has been on the runq for long enough.
Please note that there are a number of other things that are taken into
consideration when placing threads on qs and when stealing them, and
that changing these variables from their default values is at your own risk.
I'm currently working on optimizations to reduce thread migrations, but
we don't have a target for integration yet.
Rafael
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
