From: Ove Karlsen <ove.karlsen@paradoxuncreated.com>
To: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Help low-jitter man.
Date: Wed, 07 Nov 2012 01:45:13 +0100 [thread overview]
Message-ID: <op.wndodnkz1c32bs@localhost.localdomain> (raw)
In-Reply-To: <50993696.8040006@paradoxuncreated.com>
On Tue, 06 Nov 2012 17:11:02 +0100, Ove Karlsen
<ove.karlsen@paradoxuncreated.com> wrote:
> Den 06.11.2012 16:40, skrev Ove Karlsen:
>> Heya, it`s me again. I am getting my low-jitter E5 computer, soon, and I
>> have done all the tweaks I can think of with the kernel.
>>
>> I was wondering if anyone had anything to add, any good technical
>> opinion on reducing jitter (for workstation desktop/OpenGL).
>>
>> I have a kernel with "low latency desktop" enabled. And edited
>> Kconfig.hz to 90.
>> idle=poll and tick_skew=1 in boot options.
>> Compile a shaved local kernel by doing "make localmodconfig" from a full
>> distro kernel.
>> (Also turned of high_res_timers, to get 90hz)
>>
>> CFS granularity 1158500nS. (Current setting is a bit high)
>> Reniced X to -20, to prevent X being a bottleneck.
>> Remove 60hz limit in doom 3, to avoid timing jitter.
>> http://paradoxuncreated.com/tmp/AutoExec.cfg
>>
>> Some nvidia-specific stuff on my blog aswell :
>> http://paradoxuncreated.com/Blog/wordpress/?p=2268
>>
>> A lot of people think SLAB has lower jitter than SLUB etc, aswell, and
>> some tuning with regards to what kernel options execute the least code,
>> least background activity can be done. Opinions?
>>
>> I use SLUB currently, and have turned off mem-compaction.
>> And probably all kinds of debugging, counters and tracers.
>>
>> RCU boost to 99.
>>
>> I think I have collected most the relevant data for a low-jitter linux
>> config. but in case there is additional information, I would love to
>> hear it.
>>
>> Also ACPI on or off seems to be varying opions on. Some state ACPI
>> removes SMI`s? I don`t know what is true here, and knowing that some
>> recommend 10000hz timer for "low-jitter" (which is going the completely
>> wrong way) I would like to hear your opinion on this aswell.
>>
>> Also approaching a transparent OS, with realtime-threads is interesting.
>> Such as running maintask (optionally + depencies) as realtime.
>> Unfortunately it doesn`t seem to work so well with standard FIFO. Do you
>> think deadline could help this? Accurate 0.95ms of 1ms would be
>> interesting to try.
>>
>> Also if anyone knows a linux-distro with the same philosophy throughout
>> the OS, I would be interested to know about it.
>>
>
> Also have anyone given any thoughts to vsynced HZ? And also even
> possibly dividing subhz off that, or more hz counters if neccesary.
Ok, I think after this, simple renicing seems to reduce significant
amounts of jitter. So then the question becomes, how far can you take
renice.
Peace Be With you.
prev parent reply other threads:[~2012-11-07 0:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 15:40 Help low-jitter man Ove Karlsen
2012-11-06 16:11 ` Ove Karlsen
2012-11-07 0:45 ` Ove Karlsen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.wndodnkz1c32bs@localhost.localdomain \
--to=ove.karlsen@paradoxuncreated.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox