Re: [PATCH][0/3] Scheduler policies for staircase

Re: [PATCH][0/3] Scheduler policies for staircase

[Maciej Soltysiak]

Con,

I have been using SCHED_BATCH on two machines now with expected
results. So this you might consider this as another success report :-)

Do you think that these schedulers could come into the mainline
soon? Would you submit them to Linus without the staircase scheduler
or would you rather wait for the whole bunch of changes to get
rock-stable ?

Best regards,
Maciej

Re: Scheduler policies for staircase

[Con Kolivas]

Maciej Soltysiak writes:

> Con,
> 
> I have been using SCHED_BATCH on two machines now with expected
> results. So this you might consider this as another success report :-)

Great. Thanks for the report. I too use them all day every day on each 
machine I have with distributed computing clients so they're pretty well 
tested.

> Do you think that these schedulers could come into the mainline
> soon? Would you submit them to Linus without the staircase scheduler
> or would you rather wait for the whole bunch of changes to get
> rock-stable ?

It could easily be modified to suit the current scheduler. Obviously I want 
my scheduler to be considered for mainline at some stage in the future but 
there needs to be a good reason for that to occur, and the 12 other 
schedulers out there need to also be tested (we better hurry up or it could 
be twice that soon :P). At this stage I'll hold onto these patches and see 
what happens. I'd rather not have to rewrite it to suit the current 
scheduler and go through all the bugtesting again since there isn't a 
burning need for this scheduler policy in mainline at the moment. The 
lack of a large amount of feedback about staircase shows that most people 
aren't really interested in the cpu scheduler at the moment anyway.

Cheers,
Con

Re: Scheduler policies for staircase

[Con Kolivas]

Takashi Iwai writes:

> At Wed, 04 Aug 2004 10:40:26 +1000,
> Con Kolivas wrote:
>> schediso - this implements soft real time scheduling for non-privileged 
>> tasks (isochronous scheduling).
> 
> I'd love to see SCHED_ISO is introduced.
> It helps the normal audio streaming.
> 
> (but not sure about the video streaming - what happens when the stream
> handling is CPU bound?)

I use "streamer" in sched iso mode, and do the video encoding in a separate 
application (mencoder) through a pipe. So it's a simple threading issue 
where the capture thread is run in sched iso, and the cpu bound encoding 
sched normal.

Cheers,
Con

Re: Scheduler policies for staircase

[Daniel Gryniewicz]

On Wed, 2004-08-04 at 16:45 +1000, Con Kolivas wrote:
> Maciej Soltysiak writes:
> 
> > Con,
> > 
> > I have been using SCHED_BATCH on two machines now with expected
> > results. So this you might consider this as another success report :-)
> 
> Great. Thanks for the report. I too use them all day every day on each 
> machine I have with distributed computing clients so they're pretty well 
> tested.
> 
> > Do you think that these schedulers could come into the mainline
> > soon? Would you submit them to Linus without the staircase scheduler
> > or would you rather wait for the whole bunch of changes to get
> > rock-stable ?
> 
> It could easily be modified to suit the current scheduler. Obviously I want 
> my scheduler to be considered for mainline at some stage in the future but 
> there needs to be a good reason for that to occur, and the 12 other 
> schedulers out there need to also be tested (we better hurry up or it could 
> be twice that soon :P). At this stage I'll hold onto these patches and see 
> what happens. I'd rather not have to rewrite it to suit the current 
> scheduler and go through all the bugtesting again since there isn't a 
> burning need for this scheduler policy in mainline at the moment. The 
> lack of a large amount of feedback about staircase shows that most people 
> aren't really interested in the cpu scheduler at the moment anyway.
> 

I've been using CK for a while, and I've felt that the staircase was
better.  I have some machines with staircase, and some (work machines)
with mainline, and the staircase "feels" better.  However, I have no
hard numbers, so I haven't spoken up.  I suspect I'm far from alone.  I
understand the lack of a pressing need to replace the mainline
scheduler, but I'll personally continue using staircase as long as
you're putting it out.

(I breifly tried Nick's as well, and it seemed the same as mainline.
But, again, no numbers, and that was a while ago.)

Daniel

Re[2]: Scheduler policies for staircase

[Maciej Soltysiak]

>> > Con,
>> > 
>> > I have been using SCHED_BATCH on two machines now with expected
>> > results. So this you might consider this as another success report :-)
>> 
>> Great. Thanks for the report. I too use them all day every day on each
>> machine I have with distributed computing clients so they're pretty well
>> tested.
I forgot to mention about something.

I totally deadlocked my machine just after setting the
/proc/sys/kernel/compute to 1 with
# echo 1 > /proc/sys/kernel/computer


The machine is 2x1G p3, and the kernel was SMP and I had experimentally
seti@home running in SCHED_BATCH mode in screen.

It was 2.6.8-rc1 with ck patches from:
http://ck.kolivas.org/patches/2.6/2.6.7/2.6.8-rc1/

I used these patches on 2.6.8-rc1 from it (of course in the proper
order:
__cleanup_transaction-latency-fix.patch
crq-fixes.diff
defaultcfq.diff
filemap_sync-latency-fix.patch
from_2.6.8-rc1_to_staircase7.A
get_user_pages-latency-fix.patch
jbd-recovery-latency-fix.patch
journal_clean_checkpoint_list-latency-fix.patch
kjournald-smp-latency-fix.patch
prune_dcache-latency-fix.patch
schedbatch2.3.diff
schediso2.3.diff
schedrange.diff
slab-latency-fix.patch
truncate_inode_pages-latency-fix
unmap_vmas-smp-latency-fix.patch

I haven't tried doing that again, because it is an important machine.
Just playing around with SCHED_BATCH again and reporting it.
I think I'll try to experiment on some other machine with that soon.

Regards,
Maciej

Re: Scheduler policies for staircase

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

Maciej Soltysiak wrote:
>>>>Con,
>>>>
>>>>I have been using SCHED_BATCH on two machines now with expected
>>>>results. So this you might consider this as another success report :-)
>>>
>>>Great. Thanks for the report. I too use them all day every day on each
>>>machine I have with distributed computing clients so they're pretty well
>>>tested.
> 
> I forgot to mention about something.
> 
> I totally deadlocked my machine just after setting the
> /proc/sys/kernel/compute to 1 with
> # echo 1 > /proc/sys/kernel/computer
> 
> 
> The machine is 2x1G p3, and the kernel was SMP and I had experimentally
> seti@home running in SCHED_BATCH mode in screen.
> 
> It was 2.6.8-rc1 with ck patches from:
> http://ck.kolivas.org/patches/2.6/2.6.7/2.6.8-rc1/
> 
> I used these patches on 2.6.8-rc1 from it (of course in the proper
> order:
> __cleanup_transaction-latency-fix.patch
> crq-fixes.diff
> defaultcfq.diff
> filemap_sync-latency-fix.patch
> from_2.6.8-rc1_to_staircase7.A

Sorry, those were snapshot patches and not "release" patches. That bug 
was known and fixed in staircase 7.E which was released with 2.6.7-ck6; 
2.6.8-rc2-mm2 did not have that bug either.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]