On Sun, 2014-07-27 at 02:09 -0700, Sergey Oboguev wrote: > On Sat, Jul 26, 2014 at 9:02 PM, Mike Galbraith > <umgwanakikb...@gmail.com> wrote: > > On Sat, 2014-07-26 at 11:30 -0700, Sergey Oboguev wrote: > >> On Sat, Jul 26, 2014 at 1:58 AM, Mike Galbraith > >> <umgwanakikb...@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. > > > You are abusing realtime > > I am unsure why you would label priority ceiling for locks and priority > protection for other forms of time-urgent sections as an "abuse".
Ok, maybe "abuse" is too strong. I know there are reasons why people do what they do, even when it may look silly to me. I didn't like what I saw in case you couldn't tell, but lucky you, you're not selling it to me, you're selling it to maintainers. I CCd them, so having voiced my opinion, I'll shut up and listen. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
