On Sat, Aug 9, 2014 at 6:04 AM, Mike Galbraith wrote:
> You are not going to convince me that it is cool to assign an imaginary
> priority to a SCHED_FIFO class task, and still call the resulting mutant
> a SCHED_FIFO class task. Those things have defines semantics. It is
> not ok for a SCHED_FIF
On Sun, 2014-08-10 at 05:13 +0200, Mike Galbraith wrote:
> On Sat, 2014-08-09 at 20:04 +0200, Andi Kleen wrote:
> > > NAK. There it is, my imaginary NAK to imaginary realtime priorities :)
> >
> > Ok, but do you have any alternative proposal yourself how to solve the
> > lockholder preemption p
On Sat, 2014-08-09 at 20:04 +0200, Andi Kleen wrote:
> > NAK. There it is, my imaginary NAK to imaginary realtime priorities :)
>
> Ok, but do you have any alternative proposal yourself how to solve the
> lockholder preemption problem? I assume you agree it's a real problem.
>
> Just being nega
> NAK. There it is, my imaginary NAK to imaginary realtime priorities :)
Ok, but do you have any alternative proposal yourself how to solve the
lockholder preemption problem? I assume you agree it's a real problem.
Just being negative is not very constructive.
-Andi
--
To unsubscribe from this
On Sat, 2014-08-09 at 01:38 -0700, Sergey Oboguev wrote:
> On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith
> wrote:
>
> > I see subversion of a perfectly functional and specified mechanism
>
> Just wondering if the following line of thinking would sound just as much an
> anathema from your pers
On Fri, 2014-08-08 at 13:11 -0700, Sergey Oboguev wrote:
> On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith
> wrote:
>
> > task priority cannot be used by any task to describe a critical section.
> > I assert that is that there is _zero_ critical section information present.
>
> This appears to
On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith wrote:
> I see subversion of a perfectly functional and specified mechanism
Just wondering if the following line of thinking would sound just as much an
anathema from your perspective or perhaps a bit less terrible...
Proceeding from the observatio
On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith wrote:
> task priority cannot be used by any task to describe a critical section.
> I assert that is that there is _zero_ critical section information present.
This appears to be the crux of our disagreement.
This assertion is incorrect. The use of
On Wed, 2014-08-06 at 18:26 -0700, Sergey Oboguev wrote:
> On Tue, Aug 5, 2014 at 10:41 PM, Mike Galbraith
> wrote:
(ok, seems you're not addressing the reasonable, rather me;)
> The only reason why anyone would want to use DPRIO instead of regular nice in
> this case is because it might be unk
On Tue, Aug 5, 2014 at 10:41 PM, Mike Galbraith
wrote:
>> > SCHED_NORMAL where priority escalation does not work as preemption proofing
>>
>> Remember, DPRIO is not for lock holders only.
>>
>> Using DPRIO within SCHED_NORMAL policy would make sense for an application
>> that
>> has "soft" time-
On Wed, 2014-08-06 at 07:41 +0200, Mike Galbraith wrote:
> You're reading me entirely wrong, I'm not trying to discourage you from
> inventing a better bullet, I just think this particular bullet is a dud.
Anyway, I'll try to assume you're talking to the _reasonable_ people on
this list in any re
On Tue, 2014-08-05 at 16:28 -0700, Sergey Oboguev wrote:
> On Sun, Aug 3, 2014 at 2:56 AM, Mike Galbraith
> wrote:
>
> > SCHED_NORMAL where priority escalation does not work as preemption proofing
>
> Remember, DPRIO is not for lock holders only.
>
> Using DPRIO within SCHED_NORMAL policy wou
On Sun, Aug 3, 2014 at 2:56 AM, Mike Galbraith wrote:
> SCHED_NORMAL where priority escalation does not work as preemption proofing
Remember, DPRIO is not for lock holders only.
Using DPRIO within SCHED_NORMAL policy would make sense for an application that
has "soft" time-urgent section where
On Sun, Aug 3, 2014 at 10:30 AM, Andi Kleen wrote:
>> (One example might be virtual machine that runs guest operating system that
>> is
>> not paravirtualized or can be paravirtualized only to a limited extent. The
>> VM
>> might guess that preemption of VCPU thread that is processing events suc
On Sun, Aug 3, 2014 at 1:30 AM, Pavel Machek wrote:
> it seems to be a security issue to me.
> If root renices the application to high nice value, application should
> not be able to work around it by the DPRIO interface.
There is no such issue.
Since 2.6.12, Linux does allow a task that had be
> (One example might be virtual machine that runs guest operating system that is
> not paravirtualized or can be paravirtualized only to a limited extent. The VM
> might guess that preemption of VCPU thread that is processing events such as
> IPI interrupts, clock interrupts or certain device inter
On Sat, 2014-08-02 at 17:43 -0700, Sergey Oboguev wrote:
> When reasoning about concurrency management it may be helpful to keep in mind
> the fundamental perspective that the problem space and solution space in this
> area are fragmented -- just as your message exemplifies as well, but it also
>
On Sat 2014-08-02 17:47:52, Sergey Oboguev wrote:
> On Wed, Jul 30, 2014 at 6:02 AM, Pavel Machek 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
On Wed, Jul 30, 2014 at 6:02 AM, Pavel Machek 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 lock
On Mon, Jul 28, 2014 at 12:24 AM, Mike Galbraith
wrote:
> On Sun, 2014-07-27 at 18:19 -0700, Andi Kleen wrote:
>> Sergey Oboguev writes:
>>
>> > [This is a repost of the message from few day ago, with patch file
>> > inline instead of being pointed by the URL.]
>>
>> Have you checked out the pree
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 c
On Sun, 2014-07-27 at 18:19 -0700, Andi Kleen wrote:
> Sergey Oboguev writes:
>
> > [This is a repost of the message from few day ago, with patch file
> > inline instead of being pointed by the URL.]
>
> Have you checked out the preemption control that was posted some time
> ago? It did essenti
On Sun, Jul 27, 2014 at 6:19 PM, Andi Kleen wrote:
>> [This is a repost of the message from few day ago, with patch file
>> inline instead of being pointed by the URL.]
>
> Have you checked out the preemption control that was posted some time
> ago? It did essentially the same thing, but somewhat
Sergey Oboguev writes:
> [This is a repost of the message from few day ago, with patch file
> inline instead of being pointed by the URL.]
Have you checked out the preemption control that was posted some time
ago? It did essentially the same thing, but somewhat simpler than your
patch.
http://
On Sun, 2014-07-27 at 02:09 -0700, Sergey Oboguev wrote:
> On Sat, Jul 26, 2014 at 9:02 PM, Mike Galbraith
> wrote:
> > On Sat, 2014-07-26 at 11:30 -0700, Sergey Oboguev wrote:
> >> On Sat, Jul 26, 2014 at 1:58 AM, Mike Galbraith
> >> wrote:
> >> > On Fri, 2014-07-25 at 12:45 -0700, Sergey Obogu
On Sat, Jul 26, 2014 at 9:02 PM, Mike Galbraith
wrote:
> On Sat, 2014-07-26 at 11:30 -0700, Sergey Oboguev wrote:
>> On Sat, Jul 26, 2014 at 1:58 AM, Mike Galbraith
>> wrote:
>> > On Fri, 2014-07-25 at 12:45 -0700, Sergey Oboguev wrote:
>> >> [This is a repost of the message from few day ago, wit
On Sat, 2014-07-26 at 11:30 -0700, Sergey Oboguev wrote:
> On Sat, Jul 26, 2014 at 1:58 AM, Mike Galbraith
> 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.
On Sat, Jul 26, 2014 at 1:58 AM, Mike Galbraith
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
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 t
On Fri, Jul 25, 2014 at 1:12 PM, Andy Lutomirski wrote:
> On 07/25/2014 12:45 PM, 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
On 07/25/2014 12:45 PM, 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
[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 t
On Mon, 21 Jul 2014, Sergey Oboguev wrote:
> This patch is intended to improve the support for fine-grain parallel
This patch is no patch at all. Please read Documentation/SubmittingPatches
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
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
34 matches
Mail list logo
