hi linux
http://avm.com.pk/service.php?deal=xhwx1qc5mp0yt04
oboguev
On Fri, Sep 26, 2014 at 6:23 AM, Peter Zijlstra wrote:
>> This is a replica of "[PATCH 1/2] dprio" (posted yesterday for 3.16.3)
>> rebased now for the current tip (3.17.0-rc6).
>>
> 2 lines of changelog for a ~1300 line patch, you must be kidding, right?
>
> What problem is it solving and why do
This is a replica of "[PATCH 1/2] dprio" (posted yesterday for 3.16.3)
rebased now for the current tip (3.17.0-rc6).
Signed-off-by: Sergey Oboguev
---
Documentation/sysctl/kernel.txt | 14 +
fs/exec.c | 8 +
include/linux/dprio.h | 129
g 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.
More detailed description can be found in:
https://raw.githubusercontent.com/oboguev/dprio/master/dprio.txt
and also in the accompanying
Message 1/2 contains the patch to the kernel tree (3.16.3).
Message 2/2 contains the patch for man pages tree.
Signed-off-by: Sergey Oboguev
---
man2/dprio.2 | 784 +++
man2/prctl.2 | 5 +
2 files changed, 789 insertions(+)
diff --git
Message 1/2 contains the patch to the kernel tree (3.16.3).
Message 2/2 contains the patch for man pages tree.
Signed-off-by: Sergey Oboguev
---
Documentation/sysctl/kernel.txt | 14 +
fs/exec.c | 8 +
include/linux/dprio.h | 129 +
include/linux
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 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 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 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
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
han dprio. I compared dprio vs. schedctl in the write-up
https://raw.githubusercontent.com/oboguev/dprio/master/dprio.txt
To quote from there,
[--- Quote ---]
The Solaris schedctl [...]
does not provide a way to associate a priority with the resource
whose lock is being held (or, more generally, wi
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 re
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 i
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 supp
ism 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.
More detailed description can be found in:
https://raw.githubusercontent.com/oboguev/dprio/
ocking primitives
such as futex, with both featuring a fast path completing within the userspace.
More detailed description can be found in:
https://raw.githubusercontent.com/oboguev/dprio/master/dprio.txt
The patch is currently based on 3.15.2.
Patch file:
https://github.com/oboguev/dprio/blob/mast
21 matches
Mail list logo
