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

Message-ID: <m33a6e3ogo.fsf@lugabout.jhcloos.org>
Date:	Tue, 22 Sep 2009 12:58:55 -0400
From:	James Cloos <cloos@...loos.com>
To:	lkml <linux-kernel@...r.kernel.org>
Cc:	Mike Galbraith <efault@....de>,
	Ulrich Lukas <stellplatz-nr.13a@...enparkplatz.de>
Subject: Re: Poor desktop responsiveness with background I/O-operations

>>>>> "Mike" == Mike Galbraith <efault@....de> writes:

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

Yes, I wanted to try that for this, but given how long it takes to
compile a kernel on this box, and how long it takes to get everything
up so that I can test my real-life load, added to the difference in
performance after each day of uptime, I could do at best one kernel
per day; it would take weeks to finish.

That said, I jsut took a look at the git log for my /boot/grub repo
and can confirm that the last really good kernel -- the one I had up
for more than a month for the first time in years -- was pulled 
between 2.6.30-rc6 and 2.6.30-rc7 and installed on 2009/05/17 which,
since I keep .config in git in my compile repo, lets me narrow down
the make oldconfig to 2009/05/17 18:37:24Z.

So, whatever Linus' tree looked like on that date is GOOD.  His last
commit before that was 0f6f49a8cd0163fdb1723ed29f01fc65177108dc.

My next make oldconfig was on 2009/06/25 04:32:03Z, when I started
testing the radeon kms.  (I'm back to non-KMS now.)  There were too
many issues directly caused by KMS itself for me to comment on non-
KMS kernel issues from the kernels I ran with KMS enabled.

My return from KMS as on 2009/08/31; Linus' last commit before I did
that was adda766193ea1cf3137484a9521972d080d0b7af.

To give an idea of how little that narrows things:

  :; git log 0f6f49a8cd..adda766193|egrep -c ^commit
  12094

For those who use the tars, that means 30-rc6 was fast and 31-rc8 slow.

Mike> Git doesn't cause me any woes whatsoever, but my box's primary
Mike> drive isn't a slow laptop drive, ram isn't tight, 

That does make a difference.  Git is *great* when it fits into ram, but
a pull or merge on a clone of Linus' tree takes a quarter gig of VM on
x86-32, which guarantees paging, including to the swap partitions. (The
laptop is old enough to support three platters — including the optical —
so I have my primary swap partition on the second drive to reduce some
of the load to the / /var /boot drive.  The first disk's swap partition
only gets hit when I boot w/o the second drive.  It helps.)

The problem isn't that paging occurs, but rather that now, when
paging occurs, said paging is much slower than it had been.

IOW, the priority of paging vs other disk I/O has changed for the worse,
at some point after 0f6f49a8cd and before adda766193.  But, as I wrote
above, to actually test kernels between those to determine where would
take weeks.

-JimC
-- 
James Cloos <cloos@...loos.com>         OpenPGP: 1024D/ED7DAEA6
--
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/