linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <loom.20121005T132825-464@post.gmane.org>
Date:	Fri, 5 Oct 2012 12:04:29 +0000 (UTC)
From:	el es <el.es.cr@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: The uncatchable jitter, or may the scheduler wars be over?

Hello,

first of all, the posts that inspired me to write this up,
were from Uwaysi Bin Kareem (paradoxuncreated dot com).

Here is what I think:
could the source of graphic/video jitter as most people 
perceive it, be something that could be technically defined 
as 'graphic buffer underrun', caused by the scheduler 
unable to align the deadline for some userspace programs
that are crucial to video/opengl output v-refresh, that 
being really HARD RT ? As in, say the scheduler could 
sometimes decide to preempt the userspace in the middle of
OpenGL/fb call [pretty easy to imagine this : userspace that
often blocks on calls to the video hardware, or has a
usespace thread that does that, and is unable to finish
some opengl pipeline calls before end of its slice, or
in case of misalignment, can execute enough commands to
create one (or several) frame(s), and then is cut in the 
middle of creating another one and has to wait for its 
turn again, and in the mean time, vsync/video buffer swap 
occurs, and that last frame is lost/discarded/created with
time settings from previous slice which are wrong]

Bearing in mind, that the most length the video/fb/opengl
buffer can have, is probably 3 (triple buffering as in 
some game settings), as opposed to (at least some) 
sound hw which can have buffers several ms long,
it's not hard to imagine what happens if userspace cannot
make it in time to update the buffer, causing 'underruns'.

This would also explain why it doesn't matter to 'server'
people - they don't have RT video hw/buffers they care for...
(but they tune the below for max throughput instead)

But whether it is measurable or not - I don't know.

The OP (Uwaysi) has been fiddling with HZ value and the
averaging period of the scheduler (which he called 'filter')
(and granularity too). He's had some interesting results IMO.

Hope the above makes sense and not much gibberish :)

Lukasz

--
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/