* Paul Mackerras ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers writes: > > > Sorry for self-reply, but I thought, in the past, of a way to make this > > possible. > > > > It would imply the creation of a new vsyscall : vgetschedperiod > > > > It would read a counter that would increment each time the thread is > > scheduled out (or in). It would be a per thread counter > > It's very hard to do a per-thread counter in the VDSO, since threads > in the same process see the same memory, by definition. You'd have to > have an array of counters and have some way for each thread to know > which entry to read. Also you'd have to find space for tens or > hundreds of thousands of counters, since there can be that many > threads in a process sometimes. > > Paul. >
Crazy ideas : Could we do something along the lines of the thread local storage ? Or could we map a per-thread page that would contradict this "definition" ? Or can we move down the beginning of the user-space thread stack of 4 bytes (it's already put at a random address anyway) and use these 32 bits to put our variable ? We don't care if userspace also modifies it; the kernel would blindly increment it, so there would be no security concerns involved. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/