Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-08-19 Thread Peter Zijlstra
On Sun, Aug 14, 2016 at 04:27:05PM +0200, Tommaso Cucinotta wrote: > Hi, > > this is a rework of the cpudeadline bugfix and speed-up patch-set, that > integrates all comments received so far from Luca, Juri and Peter. > > Compared with the previous post, here: > -) I'm keeping out the minimally

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-08-19 Thread Peter Zijlstra
On Sun, Aug 14, 2016 at 04:27:05PM +0200, Tommaso Cucinotta wrote: > Hi, > > this is a rework of the cpudeadline bugfix and speed-up patch-set, that > integrates all comments received so far from Luca, Juri and Peter. > > Compared with the previous post, here: > -) I'm keeping out the minimally

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-08-14 Thread Tommaso Cucinotta
Hi, this is a rework of the cpudeadline bugfix and speed-up patch-set, that integrates all comments received so far from Luca, Juri and Peter. Compared with the previous post, here: -) I'm keeping out the minimally invasive bugfix, as it's already been merged in tip/sched/core -) I moved some

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-08-14 Thread Tommaso Cucinotta
Hi, this is a rework of the cpudeadline bugfix and speed-up patch-set, that integrates all comments received so far from Luca, Juri and Peter. Compared with the previous post, here: -) I'm keeping out the minimally invasive bugfix, as it's already been merged in tip/sched/core -) I moved some

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-07-19 Thread Tommaso Cucinotta
Hi, this is a rework of the cpudeadline bugfix and speed-up patch-set, that integrates all comments received so far from Luca and Juri. The first patch is a minimally invasive (1-line) fix for the deadline wrap-around bug. This leaves some weirdness in how cpudl_change_key() is called.

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-07-19 Thread Tommaso Cucinotta
Hi, this is a rework of the cpudeadline bugfix and speed-up patch-set, that integrates all comments received so far from Luca and Juri. The first patch is a minimally invasive (1-line) fix for the deadline wrap-around bug. This leaves some weirdness in how cpudl_change_key() is called.

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-19 Thread Tommaso Cucinotta
Hi all, I took Luca's advice to isolate the deadline wrap-around bugfix with a first minimally invasive patch (1-line). This leaves some weirdness in how cpudl_change_key() is called. Therefore, the second patch does a minimum of refactory to make things more explicit and clear. The 3rd patch

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-19 Thread Tommaso Cucinotta
Hi all, I took Luca's advice to isolate the deadline wrap-around bugfix with a first minimally invasive patch (1-line). This leaves some weirdness in how cpudl_change_key() is called. Therefore, the second patch does a minimum of refactory to make things more explicit and clear. The 3rd patch

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-18 Thread Juri Lelli
Hi Tommaso, On 18/05/16 00:43, Tommaso Cucinotta wrote: > On 17/05/2016 13:46, luca abeni wrote: > >Maybe the ... change can be split in a separate > >patch, which is a bugfix (and IMHO uncontroversial)? > > Ok, the bugfix alone might look like the attached. Couldn't avoid > the little

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-18 Thread Juri Lelli
Hi Tommaso, On 18/05/16 00:43, Tommaso Cucinotta wrote: > On 17/05/2016 13:46, luca abeni wrote: > >Maybe the ... change can be split in a separate > >patch, which is a bugfix (and IMHO uncontroversial)? > > Ok, the bugfix alone might look like the attached. Couldn't avoid > the little

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-17 Thread Tommaso Cucinotta
On 17/05/2016 13:46, luca abeni wrote: Maybe the ... change can be split in a separate patch, which is a bugfix (and IMHO uncontroversial)? Ok, the bugfix alone might look like the attached. Couldn't avoid the little refactoring of the multiple occurrences of the same loop up the heap into the

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-17 Thread Tommaso Cucinotta
On 17/05/2016 13:46, luca abeni wrote: Maybe the ... change can be split in a separate patch, which is a bugfix (and IMHO uncontroversial)? Ok, the bugfix alone might look like the attached. Couldn't avoid the little refactoring of the multiple occurrences of the same loop up the heap into the

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-17 Thread luca abeni
Hi all, On Mon, 16 May 2016 18:00:04 +0200 Tommaso Cucinotta wrote: > Hi, > > looking at the SCHED_DEADLINE code, I spotted an opportunity to > make cpudeadline.c faster, in that we can skip real swaps during > re-heapify()ication of items after addition/removal. As

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-17 Thread luca abeni
Hi all, On Mon, 16 May 2016 18:00:04 +0200 Tommaso Cucinotta wrote: > Hi, > > looking at the SCHED_DEADLINE code, I spotted an opportunity to > make cpudeadline.c faster, in that we can skip real swaps during > re-heapify()ication of items after addition/removal. As such ops > are done under a

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-16 Thread Tommaso Cucinotta
Hi, looking at the SCHED_DEADLINE code, I spotted an opportunity to make cpudeadline.c faster, in that we can skip real swaps during re-heapify()ication of items after addition/removal. As such ops are done under a domain spinlock, it sounded like an interesting try. Indeed, I've got a speed-up

SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-16 Thread Tommaso Cucinotta
Hi, looking at the SCHED_DEADLINE code, I spotted an opportunity to make cpudeadline.c faster, in that we can skip real swaps during re-heapify()ication of items after addition/removal. As such ops are done under a domain spinlock, it sounded like an interesting try. Indeed, I've got a speed-up