linux-kernel - Re: The uncatchable jitter, or may the scheduler wars be over?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 05 Nov 2012 09:34:38 +0100
From:	Ove Karlsen <ove.karlsen@...adoxuncreated.com>
To:	Lukasz Sokol <el.es.cr@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: The uncatchable jitter, or may the scheduler wars be over?

On Sun, 04 Nov 2012 18:03:58 +0100, Lukasz Sokol <el.es.cr@...il.com>  
wrote:

> A word of addition,
>
> On Sun, Nov 4, 2012 at 2:04 PM, Uwaysi Bin Kareem
> <uwaysi.bin.kareem@...adoxuncreated.com> wrote:
> [snip]
>>
>> Also like I stated elsewhere, since daemons seem to make a difference,
>> optimally putting daemons or processes that can, on a low-jitter queue,
>> transparent to the user, seems optimal. Unfortunately realtime is not  
>> quite
>> working as one would expect, causing input to be choked at times, if you
>> want to have one main app, and the rest on sched_other, as a low-jitter
>> queue. So I am still iterating this.
>
> Hard real time kernel, will make the situation even worse: there the  
> userspace
> will get preempted always and no matter what it is doing; RT means here,
> the userspace will /get/ the slice, but whether the slice will be  
> enough, no one
> can guarantee but whoever wrote the userspace.
> It's the userspace that must decide 'do I have enough time to run
> another rendering loop within
> this time slice (or before vsync is imminent)'.
>
> (As in: real time is not 'as fast as possible' but 'as fast as
> specified' and the specification
> need to be within reason).
>
>>
> [snip]
>> Peace Be With You.
>
> Lukasz

I meant realtime-thread here, not added preemption points, for  
realtime-behaviour.
But I understand your point. So "low-jitter" is ofcourse the sweetspot,  
where you have just enough interrupts and preemption points, for exactly  
that, but not too much.

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/