linux-kernel - Re: [PATCH RFC] sched: deferred set priority (dprio)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Jul 2014 12:29:09 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Sergey Oboguev <oboguev.public@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH RFC] sched: deferred set priority (dprio)

On Sun, 2014-07-27 at 02:09 -0700, Sergey Oboguev wrote: 
> On Sat, Jul 26, 2014 at 9:02 PM, Mike Galbraith
> <umgwanakikbuti@...il.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
> >> <umgwanakikbuti@...il.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/