On Mon, 30 Oct 2017, Peter Zijlstra wrote: > > isolcpus is the *right* approach here because you are micromanaging the OS > > and are putting dedicated pieces of software on each core. > > That is what you want, and cpusets should allow for that just fine. Well yes a cpuset of one processor I guess. > > A cgroup suggests that threads would be scheduled over multiple cores > > which is *not* what you want. > > No, that suggestion is false. cpusets should allow you to isolate > individual CPUs just fine. > > > cgroup has to do something with containers > > Sod containers. That's just modern group think. cpusets existed long > before all that wankery and it should very well retain the original use > cases. Historically cpusets were not used for cpu isolation. They were used to restrict applications threads to sets of cpus for performance reasons. And we are here dealing with individual processors. > That said, I know there's problems with cpusets, and those should be > fixed. But that doesn't mean isolcpus is anything other than a vile > hack. Controlling the way an individual processor works would be best done with some kind of configuration in sysfs. I.e. /sys/cpu/<xx>/no_sched or so. In lieu of that I think isolcpus is definitely better than a cpuset and it is the only way that traditionally processor handling of the OS has been restricted. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|