Bug 468044
Summary: | latencytop: multi-second latency during system update | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexis Deruelle <alexis.deruelle> | ||||||
Component: | thunderbird | Assignee: | Christopher Aillon <caillon> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 10 | CC: | gecko-bugs-nobody, kernel-maint, mcepl | ||||||
Target Milestone: | --- | Keywords: | Triaged | ||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-12-18 06:37:31 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
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. Created attachment 321242 [details]
latencytop capture #2
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 ! 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? 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 gah, jumpy touchpad. short answer: ext3 sucks. 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 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 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. |
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