Re: [patch] sched_[set|get]_affinity() syscall, 2.4.15-pre9

Mark Hahn
2001-11-23T00:37:26Z

> CPUs, because the scheduling decision was moved away from where it really
> should take place: the scheduler. I'm sure I'm missing something, though.

only that it's nontrivial to estimate the migration costs, I think.
at one point, around 2.3.3*, there was some effort at doing this -
or something like it. specifically, the scheduler kept track of
how long a process ran on average, and was slightly more willing
to migrate a short-slice process than a long-slice. "short" was
defined relative to cache size and a WAG at dram bandwidth.

the rationale was that if you run for only 100 us, you probably
don't have a huge working set. that justification is pretty thin,
and perhaps that's why the code gradually disappeared.

hmm, you really want to monitor things like paging and cache misses,
but both might be tricky, and would be tricky to use sanely.
a really simple, and appealing heuristic is to migrate a process
that hasn't run for a long while - any cache state it may have had
is probably gone by now, so there *should* be no affinity.

regards, mark hahn.