2012-11-05 20:34:47

by Ove Karlsen

[permalink] [raw]
Subject: Re: sched: SCHED_DEADLINE v6

On Mon, 05 Nov 2012 21:23:41 +0100, Martin <[email protected]> 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@Millennium:~/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@Millennium:~/Kildekode/sched_deadline-schedtool-dl$
>>
>> On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem
>> <[email protected]> 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 [email protected]
>> 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.