On Tue, May 12, 2015 at 09:35:25PM -0700, Andy Lutomirski wrote: > On Tue, May 12, 2015 at 5:52 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > >> > So if then a prctl() (or other system call) could be a shortcut > >> > to: > >> > > >> > - move the task to an isolated CPU > >> > - make sure there _is_ such an isolated domain available > >> > > >> > I.e. have some programmatic, kernel provided way for an > >> > application to be sure it's running in the right environment. > >> > Relying on random administration flags here and there won't cut > >> > it. > >> > >> No, we already have sched_setaffinity() and we should not duplicate > >> its ability to move tasks about. > > > > But sched_setaffinity() does not guarantee isolation - it's just a > > syscall to move a task to a set of CPUs, which might be isolated or > > not. > > > > What I suggested is that it might make sense to offer a system call, > > for example a sched_setparam() variant, that makes such guarantees. > > > > Say if user-space does: > > > > ret = sched_setscheduler(0, BIND_ISOLATED, &isolation_params); > > > > ... then we would get the task moved to an isolated domain and get a 0 > > return code if the kernel is able to do all that and if the current > > uid/namespace/etc. has the required permissions and such. > > > > ( BIND_ISOLATED will not replace the current p->policy value, so it's > > still possible to use the regular policies as well on top of this. ) > > I think we shouldn't have magic selection of an isolated domain. > Anyone using this has already configured some isolated CPUs and > probably wants to choose the CPU and, especially, NUMA node > themselves. Also, maybe it should be a special type of realtime > class/priority -- doing this should require RT permission IMO. I have no real argument against special permissions, but this feature is totally orthogonal to realtime classes/priorities. It is perfectly legitimate for a given CPU's single runnable task to be SCHED_OTHER, for example. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
