Messages in this thread | | | Date | Fri, 13 Jul 2001 02:06:07 +0000 (GMT) | From | Mark Hahn <> | Subject | Re: CPU affinity & IPI latency |
| |
> If the amount of data/instructions needed by all 5 processes fits in the > cache and you pin all the processes to the same CPU you'll get much > better performance than simply letting them float.
interesting. I remember that around 2.3.40, the scheduler handled "frequent-schedulers" (like lat_ctx) differently, based on how long a timeslice the proc used, relative to the estimated time to flush cache.
as I recall, it let them stay on their current CPU. like letting someone with 1 item go ahead of you in a grocery store checkout ;)
that code is mostly gone (only cacheflush_time remains); I think it morphed into the current migrate-to-longest-idle heuristic.
does anyone remember why the frequent-schedulers code was killed? just because it conflated cache-affinity with timeslice?
regards, mark hahn.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |