Message-id: <op.wnbh36ga1c32bs@localhost.localdomain>
Date:	Mon, 05 Nov 2012 21:34:44 +0100
From:	Ove Karlsen <ove.karlsen@...adoxuncreated.com>
To:	Martin <marogge@...inehome.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: sched: SCHED_DEADLINE v6

On Mon, 05 Nov 2012 21:23:41 +0100, Martin <marogge@...inehome.de> wrote:

> On 11/04/2012 09:00 PM, Uwaysi Bin Kareem wrote:
>> Nobody knows? This is really obscure for an EDF patch. Making things a
>> bit more accessible should be a priority. I think a lot of enthusiasts
>> would like to have smooth control over stuff, without windows-jitter. If
>> you can do a robot arm, jitter-free with this, then I am very  
>> interested.
>>
>> uwaysi@...lennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool  
>> -E
>> -t 500:1000 3718
>> ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not
>> implemented
>> uwaysi@...lennium:~/Kildekode/sched_deadline-schedtool-dl$
>>
>> On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
>> <uwaysi.bin.kareem@...adoxuncreated.com> wrote:
>>
>>> How does the modified schedtool work? There is no updated  
>>> documentation.
>>>
>>> http://gitorious.org/sched_deadline/schedtool-dl/commits/latest/2.6.36-dl-V3
>>>
>>>
>>> If anyone could give an example of a 1000uS period / 500uS time, with
>>> schedtool, or any other relevant information.
>>> Most examples online use parameters that are no longer supported.
>>>
>>> Peace Be With You.
>> --
>> 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/
>
> Hi,
>
> I assume the reason nobody answers is that the cpu scheduler is an  
> emotional subject.
>
> However, if you really want a smooth desktop and a deadline scheduler  
> (albeit it might not be as configurable as you seem to want it to be),  
> try BFS or the whole CK patch.
>
> http://ck-hack.blogspot.com/
>
> I have implemented it on a laptop this weekend, and I was surprised by  
> the change in user experience yet again. Mostly during 3D game play.  
> Generally the difference is felt more strongly on low end machines and  
> taxing workloads.
>
> Since you are talking about robot arms: note that BFS is not a real time  
> solution, but is designed around the physiological conditions of the  
> human perception system (where, I believe, 6 ms is equivalent to real  
> time). Maybe a similar deadline approach is useful for robot arms, no  
> idea.
>
> cu Martin
>

If you ever saw a robot-arm jitter, you`d think of it as faulty. And that  
is how people should think of their PC aswell.

Just the interrupts, preemption (points), daemons, hopefully cleverly  
arranged, to reduce jitter, is what I want.
I did already try BFS. PS: 90hz timer, is very good with BFS also, but the  
jitter-extremes are higher. Meaning large jitters last longer, while small  
jitters, seems smaller. For overall computing CFS actually has less jitter.

What would be really interesting would be to try a scheduler that tries to  
bound latencies, and have accurate timing.

There seems to be generally 3 different profiles people tuned for: Server,  
Mobile, Desktop.
Server guiless stationary, Mobile for minimal power desktop, Desktop, for  
workstation/home low-jitter high-performance.

Maybe these profiles even can be combined a bit, having several hz  
counters, and several scheduling policies.

Peace Be With You.
--
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/

Powered by blists - more mailing lists