From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Grozdan <neutrino8@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: High latency while CPU is under full load
Date: Wed, 08 Oct 2014 07:44:40 -0400 [thread overview]
Message-ID: <543523A8.1040006@gmail.com> (raw)
In-Reply-To: <CAFLt3pjkXgz9H9p=u-NATyf4C+8ybJ3fwLc=GXEjaabBZ8NF5g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]
On 2014-10-07 15:28, Grozdan wrote:
> Hi,
>
> Basically, my problem is this:
>
> I'm doing a lot of audio/video encoding on an AMD FX8350. The encoder
> process always runs at nice 10. Even so, my whole system feels very
> sluggish. Switching between different app windows and/or virtual
> desktops takes up usually 3-5 seconds giving the impression that there
> is not enough processing power. Browsing the web is also severely
> impacted.
>
> I had to tune CFS in order to be (much) more responsive during an
> encoding session. This has worked out pretty well thus far, but it is
> my opinion that the user should *not* need to fiddle with buttons to
> make his system respond fluently even under high load. The below is
> what I had to do in order to get a snappy system during such load
>
> kernel.sched_nr_migrate = 64
> kernel.sched_latency_ns = 65000000
> kernel.sched_wakeup_granularity_ns = 100000
> kernel.sched_min_granularity_ns = 100000
> kernel.sched_migration_cost_ns = 7000000
>
> I have tried 3 different kernels, including one compiled myself, but
> the results are the same
> Kernels I tried were: 3.11.10, 3.12 and 3.16.4 (self-compiled)
>
> My system specs are as follows
>
> CPU: AMD FX-8350 @ 4GHz
> RAM: 16GB DDR1333
> GPU: NVIDIA GTX 560 with NV blob driver
> HDD: Seagate Constellation ES.3 128MB cache
> Desktop: KDE 4.11
>
Are you using a kernel with CONFIG_PREEMPT=y? I've personally found
that that can help hugely with UI sluggishness (and also tends to get
better results when doing stuff like live video capture), although to
get this you may need to build the kernel yourself. Also, I would
suggest trying the deadline I/O scheduler; I've found it provides much
better latency than CFQ for most workloads, and you almost certainly
don't need I/O priorities. I've actually got a similar setup (FX-8320 @
4GHz, 16GB DDR3-1600, High-end storage, and a Radeon R7-240 GPU), and
had similar issues when doing processing of big (>500MB) images in GIMP,
and using a CONFIG_PREEMPT enabled kernel and the deadline I/O scheduler
has pretty much resolved all of these issues.
Additionally, try with KDE's 'semantic desktop' functionality turned
off, this eats a huge amount of disk and memory bandwidth, and can
easily bring a system to it's knees. Furthermore, unless you can
reproduce things using nouevau instead of the NV driver, you're not as
likely to get a lot of help.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
next prev parent reply other threads:[~2014-10-08 11:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 19:28 High latency while CPU is under full load Grozdan
2014-10-08 5:30 ` Mike Galbraith
2014-10-08 11:44 ` Austin S Hemmelgarn [this message]
2014-10-08 11:59 ` Grozdan
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=543523A8.1040006@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neutrino8@gmail.com \
/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