linux-kernel - Re: High latency while CPU is under full load

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

Date:	Wed, 08 Oct 2014 07:30:55 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Grozdan <neutrino8@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: High latency while CPU is under full load

On Tue, 2014-10-07 at 21:28 +0200, 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

You shouldn't have to do any CFS twiddling.

I kinda doubt it's the CPU scheduler, would be more inclined to suspect
mm/IO.  You could try the BFQ IO scheduler, that showed some promise on
my little box when doing hefty IO to my single speck of spinning rust.

If you want to try it, and can't find it, I can send you a quilt tarball
to plug into 3.16.4. 

> kernel.sched_nr_migrate = 64
> kernel.sched_latency_ns = 65000000
> kernel.sched_wakeup_granularity_ns = 100000

100us... that's a bad idea.

> kernel.sched_min_granularity_ns = 100000

As is that, you'll likely be better off un-twiddling knobs.

> 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

Not that I think NV is to blame, but you should probably try reproducing
the interactivity problem without that binary blob.  It's suspect just
for being a proprietary black hole, the perfect target to blame for all
your open source kernel woes ;-)

What are you encoding with what tools?  What does vmstat 1 look like
while box is working hard?  (With stock scheduler knobs I mean, and just
a few seconds)  Posting something easily reproducible (do this with that
tool) may help too.

-Mike

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