linux-kernel - Re: Poor desktop responsiveness with background I/O-operations

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]

Message-Id: <1253603193.6875.118.camel@marge.simson.net>
Date:	Tue, 22 Sep 2009 09:06:33 +0200
From:	Mike Galbraith <efault@....de>
To:	James Cloos <cloos@...loos.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ulrich Lukas <stellplatz-nr.13a@...enparkplatz.de>
Subject: Re: Poor desktop responsiveness with background I/O-operations

On Mon, 2009-09-21 at 15:47 -0400, James Cloos wrote:
> FWIW, I did not notice any problems with the last kernel I had compiled
> in the -- IIRC -- 29-rc timeframe.  Or maybe it was the 30-rc timeframe.
> 
> I had that kernel up for soemthing like five weeks, on a busy, low-ram
> laptop, w/o and long pauses or other noticeable pain.  For at least two
> years before that the best this laptop could manage before latency
> became horrific was a fortnight, and weekly reboots were desirable.
> 
> Unfortunately, before I could send out a congratulatory note (I wanted
> to first confirm that the result remained) I pulled up and started see-
> ing even worse latency then ever.
> 
> Turning ext4 barriers off helped avoid some of the new latency, and my
> current compile (master as of the 17th) is much better than .31 was.
> 
> But long pauses still occur whenever paging and backgound i/o-bound
> tasks interact.
> 
> There was a major regression in paging performance either .30 or .31
> (see above).  Interestingly, top(1) also shows less swap usage for
> the same usage patterns than with the older kernels.  I don't know
> which is cause or which is effect.

If someone has a definite good/bad cutoff for the problem they're
seeing, a git bisect (yeah, takes time) would be a good thing to try.

The "interactivity while saturating root disk" thing isn't a new problem
though, I can recall that being a problem to varying degrees forever.
(forever being defined as feb '93 -> today;)

> A git pull on a clone of Linus' tree is a great way to trigger the
> problem.  As is using Gentoo's portage to install/upgrade anything.
> (Bad python; no alligator!¹)  (Yes, that is a burlesque of the no
> doughnut joke.)

Git doesn't cause me any woes whatsoever, but my box's primary drive
isn't a slow laptop drive, ram isn't tight, and it has 4 cores.

Dunno.

If you're using the CFQ IO scheduler, IO bandwidth follows CPU nice
level, so tweaking nice tweaks both CPU and IO in one go.  ionice can
also be used to tweak IO independently.

I don't know if distros provide a tool that supports SCHED_IDLE, if so,
you can use that to set both CPU and IO usage to IDLE class in one go.

If you don't have such a tool, you can try the attached for background
loads.  Someone posted it to LKML in '98, and I've been updating/using
it for experiments ever since.  Just do schedctl -I background-job, and
the job will be as polite as CPU and IO schedulers can make it.

	-Mike

View attachment "schedctl.c" of type "text/x-csrc" (12309 bytes)