>> I've never checked it but I would have expected kswapd to stay on the >> same processor for significant periods of time. Have you experienced >> problems where kswapd bounces around on CPUs within a node causing >> workload disruption? > > When kswapd shares the same CPU as our main process it causes a measurable > drop in response time (graphs show tiny spikes at the same time memory is > freed). Would be nice to be able to ensure it runs on a different core > than our latency sensitive processes at least. We can pin processes to > subsets of cores but I don't think there's a way to keep kswapd from > waking up on any of them?
You are only talking about extream corner case and don't talk about the other hand. When number-of-nodes > nubmer-of-cpus, we have no way to avoid cpu sharing. Moreover, this is not kswapd specific isssue, every kernel thread makes the same latency ick. so, this issue should be solved more generic layer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
