Bug 468044 - latencytop: multi-second latency during system update
latencytop: multi-second latency during system update
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
10
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Christopher Aillon
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-22 11:04 EDT by Alexis Deruelle
Modified: 2009-12-18 01:37 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:37:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
latencytop capture #1 (73.29 KB, image/png)
2008-10-22 11:04 EDT, Alexis Deruelle
no flags Details
latencytop capture #2 (75.87 KB, image/png)
2008-10-23 01:14 EDT, Alexis Deruelle
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 421482 None None None Never

  None (edit)
Description Alexis Deruelle 2008-10-22 11:04:52 EDT
Created attachment 321164 [details]
latencytop capture #1

Description of problem:

latencytop reports multisecond latency that is consistent with system behaviour (jerky pointer movements, slow display updates)

Version-Release number of selected component (if applicable):

2.6.27.3-30.rc1.fc10.i686

How reproducible:

Everytime

Steps to Reproduce:
1. open your favorite apps for the job of the day (thunderbird, firefox, pidgin, gnome-terminal(s))
2. do a system update
3. et voilà
  
Actual results:

Orverloaded system

Expected results:

Overloaded system with better interactive 'feel'

Additional info:

See latencytop screen captures.

I tried to mount my main partition using relatime option, but didn't notice any noticeable improvements.

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping	: 9
cpu MHz		: 2793.176
cache size	: 512 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid xtpr
bogomips	: 5586.35
clflush size	: 64
power management:

$ cat /proc/meminfo 
MemTotal:       513216 kB
MemFree:         20044 kB
Buffers:         13688 kB
Cached:         147168 kB
SwapCached:      30856 kB
Active:         389156 kB
Inactive:        39524 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       513216 kB
LowFree:         20044 kB
SwapTotal:     1048568 kB
SwapFree:       926676 kB
Dirty:             120 kB
Writeback:           0 kB
AnonPages:      265048 kB
Mapped:          80100 kB
Slab:            29000 kB
SReclaimable:    13716 kB
SUnreclaim:      15284 kB
PageTables:       5256 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:   1305176 kB
Committed_AS:  1079492 kB
VmallocTotal:   503800 kB
VmallocUsed:      2532 kB
VmallocChunk:   501124 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB
DirectMap4k:     15808 kB
DirectMap4M:    507904 kB
Comment 1 Dave Jones 2008-10-22 11:58:04 EDT
from the looks of things, thunderbird is calling fsync.  On ext3 this means a flush of all dirty pages, and a journal flush.  With the yum update going on, you have a considerable number of pages waiting to be written out to disk.

I don't know thunderbird internals well enough to determine if it's doing fsync's excessively or not. Reassigning.
Comment 2 Alexis Deruelle 2008-10-23 01:14:52 EDT
Created attachment 321242 [details]
latencytop capture #2
Comment 3 Alexis Deruelle 2008-10-23 01:34:16 EDT
I don't particularly blame Thunderbird (see capture #2 from the same update run).

Anyway I understand that it might be related to ext3 journal syncing on disk as suggested in this article : http://kerneltrap.org/node/14148.

Is there really something kernel people can do about it or is this just a fact of life when dealing with journalled filesystems or ext3 particularly ? Would switching to ext4 or other fs help ?

How is this related to task scheduling and why the great work on CFS won't help in this case ?

I know, I know, every other OSe's insist that you leave any running  program while updating the system. I may be a fool, but being able to update FC while working in a terminal on another machine without barely noticing would be really great. So I ask :-)

This report is not specifically restricted to fc10 beta or a particular kernel version as this has been the behaviour of every single FC instalment since my regular use of yum. Yes yum is a pig !
Comment 4 Matěj Cepl 2008-10-23 07:05:30 EDT
Just to add some more links:

* our firefox bug is bug 439908
* upstream firefox bug is https://bugzilla.mozilla.org/show_bug.cgi?id=421482
* kernel discussion is http://thread.gmane.org/gmane.comp.file-systems.ext4/6840/)

I am not sure, whether it is the same problem, but it may be good read.

Dave is this the same issue?
Comment 5 Dave Jones 2008-10-23 10:30:49 EDT
there are some pending kernel patches iirc to make ext3 better, but the fsync flaw is pretty much 'designed in' to ext3.  ext4 should also improve somewhat if I understood correctly, but it's a little unproven right now.

a package update is going to create huge amounts of data to be written back to disk, so anything that fsyncs is going to cause this.  The firefox bug was a problem because it called fsync so regularly (every page load).  This is why I'm curious if thunderbird does anything excessive.

short answer: ext44
Comment 6 Dave Jones 2008-10-23 10:31:09 EDT
gah, jumpy touchpad.
short answer: ext3 sucks.
Comment 7 Bug Zapper 2008-11-25 23:07:24 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2009-11-18 04:17:59 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2009-12-18 01:37:31 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.