Messages in this thread | | | Date | Sat, 2 Aug 2014 17:47:52 -0700 | Subject | Re: [PATCH RFC] sched: deferred set priority (dprio) | From | Sergey Oboguev <> |
| |
On Wed, Jul 30, 2014 at 6:02 AM, Pavel Machek <pavel@ucw.cz> wrote: > Hi! > >> One of the intended purposes of this facility (but its not sole purpose) is to >> render a lightweight mechanism for priority protection of lock-holding critical >> sections that would be an adequate match for lightweight locking primitives >> such as futex, with both featuring a fast path completing within the >> userspace.
> Do we get a manpage describing the interface...?
At this point it is just an RFC, and the only available write-up is an article (URL is in the original message).
There has been no word from the maintainers yet whether the proposal appears to be a "go" or "no-go" in general.
Assuming the response was favorable, final polishing on the patch can be done (such as perhaps replacing or augmenting authlist by a capability), and man page can be added at this point as well.
> Would it make sense to make set_priority a "vsyscall" so it is fast enough, and delayed_set_priority does not need to be exposed to userspace?
Regular "set priority" cannot be wrapped around "deferred set priority".
"Deferred set priority" acts only on current thread.
Even more importantly, its use also relies on a thread caching the application's current knowledge of the thread priority in the userspace, and if the thread priority had been changed from the outside of the application (or even by another thread within the same application), this knowledge becomes invalid, and then the application is responsible for performing whatever recovery action is appropriate.
Thus DPRIO is not a replacement for fully-functional "set priority", but rather a specialized tool for certain use cases.
- Sergey
| |