Messages in this thread | | | Date | Sat, 26 Jul 2014 11:30:38 -0700 | Subject | Re: [PATCH RFC] sched: deferred set priority (dprio) | From | Sergey Oboguev <> |
| |
On Sat, Jul 26, 2014 at 1:58 AM, Mike Galbraith <umgwanakikbuti@gmail.com> wrote: > On Fri, 2014-07-25 at 12:45 -0700, Sergey Oboguev wrote: >> [This is a repost of the message from few day ago, with patch file >> inline instead of being pointed by the URL.] >> >> This patch is intended to improve the support for fine-grain parallel >> applications that may sometimes need to change the priority of their threads at >> a very high rate, hundreds or even thousands of times per scheduling timeslice. >> >> These are typically applications that have to execute short or very short >> lock-holding critical or otherwise time-urgent sections of code at a very high >> frequency and need to protect these sections with "set priority" system calls, >> one "set priority" call to elevate current thread priority before entering the >> critical or time-urgent section, followed by another call to downgrade thread >> priority at the completion of the section. Due to the high frequency of >> entering and leaving critical or time-urgent sections, the cost of these "set >> priority" system calls may raise to a noticeable part of an application's >> overall expended CPU time. Proposed "deferred set priority" facility allows to >> largely eliminate the cost of these system calls. > > So you essentially want to ship preempt_disable() off to userspace? >
Only to the extent preemption control is already exported to the userspace and a task is already authorized to control its preemption by its RLIMIT_RTPRIO, RLIMIT_NICE and capable(CAP_SYS_NICE).
DPRIO does not amplify a taks's capability to elevate its priority and block other tasks, it just reduces the computational cost of frequest sched_setattr(2) calls.
> > -Mike > >> Instead of executing a system call to elevate its thread priority, an >> application simply writes its desired priority level to a designated memory >> location in the userspace. When the kernel attempts to preempt the thread...
- Sergey
| |