kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #35503
[Bug 131094] Re: Heavy Disk I/O harms desktop responsiveness
Adam Niedling, thank you for your comments regarding them:
"...are you going to tell all the 165 people that are affected by this bug to open a new bug report..."
Given the Bug Description is so vague it's largely useless "heavy disk I/O causes increased iowait times", if one has a performance problem, and for hardware tracking purposes, then one would want to file a new report. For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette
"...for the same issue which is not even hardware related?"
This is speculation at best.
"If you just took a minute you could test this bug yourself instead of
require us to do all that work to test the latest mainline kernel."
I've never had heavy disk I/O affect desktop responsiveness with my
hardware, both with a HDD 3GB RAM, and now SSD with 8GB.
"I think you are just mass closing linux kernel related bugs that are
still valid and affect many people."
This is also speculation at best, and incorrect. I've never mass closed
any bugs anywhere, and your baseless accusations are not appreciated.
"Some of them have upstream bug reports which indicate that no actual
work has been done to address those issues."
One having filed an upstream bug report, on a tracker which has no
permission restrictions on who can file, is largely irrelevant if the
full hardware isn't known, it hasn't been tested in the latest mainline
kernel, it hasn't been bisected if a regression, and doesn't have
specific, objective metrics demonstrating the issue.
"So why do testing?"
Testing gets a bug report one step closer to a fix. The best question is
why do the complaining, which gets you nowhere? ;)
"Even if someone does the testing most likely no work will be done by
downstream to fix the issue."
More incorrect speculation. Downstream has the same information
requirements as upstream, as previously noted. No developer is going to
take a strong interest in working on any problem, up or down, without
it.
"So what's the point? I think doing what you're doing is just making
more harm than good."
Wasting time arguing about things previously documented and discussed ad
nauseam would be considered doing more harm than good, with the time
better spent actually doing the testing and bug report filing previously
requested.
If you have further comments, please refrain from making them in this
report, as you are not the original reporter, and it already has quite
enough "Me too!" and "Why isn't this fixed already?" comments. Instead,
you are welcome to contact me directly, and/or redirect them to the
appropriate mailing list or forum.
http://www.ubuntu.com/support/community/mailinglists might be a good
start for determining which mailing list to use.
Thank you for your understanding.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/131094
Title:
Heavy Disk I/O harms desktop responsiveness
Status in The Linux Kernel:
Fix Released
Status in The Linux Mint Distribution:
New
Status in “linux” package in Ubuntu:
Incomplete
Bug description:
Binary package hint: linux-source-2.6.22
When compared with 2.6.15 in feisty, heavy disk I/O causes increased
iowait times and affects desktop responsiveness in 2.6.22
this appears to be a regression from 2.6.15 where iowait is much lower
and desktop responsiveness is unaffected with the same I/O load
Easy to reproduce with tracker - index the same set of files with
2.6.15 kernel and 2.6.22 kernel and the difference in desktop
responsiveness is massive
I have not confirmed if a non-tracker process which does heavy disk
i/o (especially writing) replicates this yet - will do further
investigation soon
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/131094/+subscriptions