7:40 p.m.
Hi all,
I just recently installed FC3 RC3 on my Dell Inspiron 8200 laptop and
experienced _really_ wierd hard-drive performance (IDE drive). At first
I noticed it when trying to start applications such as Evolution,
FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 38 MB in 5.65 seconds = 6.72 MB/sec
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 14 MB in 4.38 seconds = 3.20 MB/sec
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 2 MB in 3.48 seconds = 588.26 kB/sec
First I was thinking PIO vs. DMA, but DMA was turned on (confirmed with
hdparm -d). I know this didn't happen with FC2 so I tested the latest
FC2 kernel (2.6.8-521) but that didn't even help.
So then I started looking at some of the processes I didn't recognize
from FC2, and actually think I found the culprit.
If I stopped the "haldaemon" service (hald) my hard-driver performance
was back to normal :
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 84 MB in 3.03 seconds = 27.74 MB/sec
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 84 MB in 3.03 seconds = 27.73 MB/sec
What is the purpose of the "haldaemon" and why is it destroying my
system performance ?
Best regards,
Steffen Persvold
7:51 p.m.
On Thu, 2004-11-04 at 13:40 -0500, Steffen Persvold wrote:
Hi all,
I just recently installed FC3 RC3 on my Dell Inspiron 8200 laptop and
experienced _really_ wierd hard-drive performance (IDE drive). At first
I noticed it when trying to start applications such as Evolution,
FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
# hdparm -t /dev/hda
don't use hdparm!
it's very unreliable for measuring performance; please use something
like tiobench (tiobench.sf.net)
8:02 p.m.
On Thu, 2004-11-04 at 19:51 +0100, Arjan van de Ven wrote:
On Thu, 2004-11-04 at 13:40 -0500, Steffen Persvold wrote:
> Hi all,
>
> I just recently installed FC3 RC3 on my Dell Inspiron 8200 laptop and
> experienced _really_ wierd hard-drive performance (IDE drive). At first
> I noticed it when trying to start applications such as Evolution,
> FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
>
> # hdparm -t /dev/hda
don't use hdparm!
it's very unreliable for measuring performance; please use something
like tiobench (tiobench.sf.net)
I'm sure that's true, however the reporter noted that performance was
degraded and that's what made him use hdparm in the first place. I'm
also getting reports from Debian users about this FWIW. (Well, with
having an optical drive and a harddrive on the same IDE cable).
Thanks,
David
8:03 p.m.
On Thu, 2004-11-04 at 19:51 +0100, Arjan van de Ven wrote:
On Thu, 2004-11-04 at 13:40 -0500, Steffen Persvold wrote:
> Hi all,
>
> I just recently installed FC3 RC3 on my Dell Inspiron 8200 laptop and
> experienced _really_ wierd hard-drive performance (IDE drive). At first
> I noticed it when trying to start applications such as Evolution,
> FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
>
> # hdparm -t /dev/hda
don't use hdparm!
it's very unreliable for measuring performance; please use something
like tiobench (tiobench.sf.net)
Arjan,
Event though I agree that hdparm -t is not the correct tool to test hard
drive performance, your missing my point. My original problem was that
Applications such as Evolution, Firefox, OpenOffice, disk access in
general was _really_ slow. Turning off the HAL daemon fixed that.
Regards,
Steffen
1:25 a.m.
On Thu, Nov 04, 2004 at 07:51:04PM +0100, Arjan van de Ven wrote:
> # hdparm -t /dev/hda
don't use hdparm!
it's very unreliable for measuring performance; please use something
like tiobench (tiobench.sf.net)
Its not that unreliable for measuring streaming I/O. Those numbers match
other reports I've seen from the old magicdev crap when there was a cdrom
as the slave and it polled
7:59 p.m.
On Thu, 2004-11-04 at 13:40 -0500, Steffen Persvold wrote:
What is the purpose of the "haldaemon" and why is it
destroying my
system performance ?
hal polls for media change on your optical drive; is your optical
drive /dev/hdb by any chance? E.g. on the same cable as /dev/hda - I've
had reports yesterday about hdparm giving bad numbers in this case.
Basically hal does this (every two seconds)
open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
close(0)
Can some kernel person comment on why this is killing performance on
the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
Cheers,
David
8:16 p.m.
On Thu, 2004-11-04 at 13:59 -0500, David Zeuthen wrote:
On Thu, 2004-11-04 at 13:40 -0500, Steffen Persvold wrote:
> What is the purpose of the "haldaemon" and why is it destroying my
> system performance ?
>
hal polls for media change on your optical drive; is your optical
drive /dev/hdb by any chance? E.g. on the same cable as /dev/hda - I've
had reports yesterday about hdparm giving bad numbers in this case.
Basically hal does this (every two seconds)
open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
close(0)
Can some kernel person comment on why this is killing performance on
the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
David,
Yes, for some reason the cdrom is attached to the same IDE channel as my
harddrive (cdrom = /dev/hdb). Not sure why Dell implemented it that way
though. Back in the good old days I learned that for best performance
you shouldn't really have two devices on the same IDE channel unless you
absolutely had to... However I don't think there is any way of changing
it, and a lot of Linux users have Dell laptops ;) ...
And your analysis matches with the behavior I see on the drive light.
When I start hdparm, the drive light stays solid for a while, but then
suddenly it stops and depending on how long the light stays solid my
transfer rate differs (and this is dependent on when I start the test
vs. the polling interval for hald). I guess the ioctl() to /dev/hdb
interrupts the /dev/hda transfer for some reason.
Thanks,
Steffen
1:27 a.m.
On Thu, Nov 04, 2004 at 01:59:48PM -0500, David Zeuthen wrote:
Basically hal does this (every two seconds)
open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
close(0)
Can some kernel person comment on why this is killing performance on
the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
Because /dev/hdb is powersaved. Every time you poll it the laptop powers up
the drive (costly on power/time), polls the TOC, replies and a second or so
later powers back down. During the power up, poll TOC sequence it locks the
bus so your IDE bus spends 1.5 of every 2 seconds jammed by the drive.
We have some bug reports for this from magicdev too.
1:34 a.m.
On Thu, 2004-11-04 at 19:27 -0500, Alan Cox wrote:
On Thu, Nov 04, 2004 at 01:59:48PM -0500, David Zeuthen wrote:
> Basically hal does this (every two seconds)
>
> open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
> ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
> close(0)
>
> Can some kernel person comment on why this is killing performance on
> the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
Because /dev/hdb is powersaved. Every time you poll it the laptop powers up
the drive (costly on power/time), polls the TOC, replies and a second or so
later powers back down. During the power up, poll TOC sequence it locks the
bus so your IDE bus spends 1.5 of every 2 seconds jammed by the drive.
We have some bug reports for this from magicdev too.
So is it even worth filing a new bug report on this then ? Is there any
way to fix this in software (kernel) ?
Regards,
Steffen
9:07 a.m.
On Thu, 2004-11-04 at 19:27 -0500, Alan Cox wrote:
On Thu, Nov 04, 2004 at 01:59:48PM -0500, David Zeuthen wrote:
> Basically hal does this (every two seconds)
>
> open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
> ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
> close(0)
>
> Can some kernel person comment on why this is killing performance on
> the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
Because /dev/hdb is powersaved. Every time you poll it the laptop powers up
the drive (costly on power/time), polls the TOC, replies and a second or so
later powers back down. During the power up, poll TOC sequence it locks the
bus so your IDE bus spends 1.5 of every 2 seconds jammed by the drive.
it sounds like HAL should measure how long such a poll takes (shouldn't
be too hard) and then add like 10 times that time to the 2 seconds
interval. On fast hw you get almost a 2 second interval but on really
slow cdroms you still can get decent performance.
9:16 p.m.
On Fri, 2004-11-05 at 09:07 +0100, Arjan van de Ven wrote:
On Thu, 2004-11-04 at 19:27 -0500, Alan Cox wrote:
> On Thu, Nov 04, 2004 at 01:59:48PM -0500, David Zeuthen wrote:
> > Basically hal does this (every two seconds)
> >
> > open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
> > ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
> > close(0)
> >
> > Can some kernel person comment on why this is killing performance on
> > the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
>
> Because /dev/hdb is powersaved. Every time you poll it the laptop powers up
> the drive (costly on power/time), polls the TOC, replies and a second or so
> later powers back down. During the power up, poll TOC sequence it locks the
> bus so your IDE bus spends 1.5 of every 2 seconds jammed by the drive.
it sounds like HAL should measure how long such a poll takes (shouldn't
be too hard) and then add like 10 times that time to the 2 seconds
interval. On fast hw you get almost a 2 second interval but on really
slow cdroms you still can get decent performance.
Another more straightforward option is of course to poll more than once
a second so the drive never goes into power saving mode and thus never
jams the bus :-). No, seriously, it would best not to poll as well, but
we do need the media change notifications.
Cheers,
David
9:15 p.m.
On Thu, Nov 11, 2004 at 03:16:27PM -0500, David Zeuthen wrote:
> > later powers back down. During the power up, poll TOC
sequence it locks the
> > bus so your IDE bus spends 1.5 of every 2 seconds jammed by the drive.
>
> it sounds like HAL should measure how long such a poll takes (shouldn't
> be too hard) and then add like 10 times that time to the 2 seconds
> interval. On fast hw you get almost a 2 second interval but on really
> slow cdroms you still can get decent performance.
Another more straightforward option is of course to poll more than once
a second so the drive never goes into power saving mode and thus never
jams the bus :-). No, seriously, it would best not to poll as well, but
we do need the media change notifications.
yeah well... need to get hardware that gives those notifications.. which is
REALLY rare.
12:42 a.m.
On Thu, Nov 11, 2004 at 03:16:27PM -0500, David Zeuthen wrote:
Another more straightforward option is of course to poll more than
once
a second so the drive never goes into power saving mode and thus never
jams the bus :-). No, seriously, it would best not to poll as well, but
we do need the media change notifications.
If you poll a lot you'll then have fun with the drives too dumb to cache
the TOC. I don't think there is one solution here, it probably requires
blacklisting the small number of problem drive types
9:09 p.m.
On Thu, 2004-11-04 at 19:27 -0500, Alan Cox wrote:
On Thu, Nov 04, 2004 at 01:59:48PM -0500, David Zeuthen wrote:
> Basically hal does this (every two seconds)
>
> open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 0
> ioctl(0, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
> close(0)
>
> Can some kernel person comment on why this is killing performance on
> the /dev/hda harddrive when the optical drive at /dev/hdb is polled?
Because /dev/hdb is powersaved. Every time you poll it the laptop powers up
the drive (costly on power/time), polls the TOC, replies and a second or so
later powers back down. During the power up, poll TOC sequence it locks the
bus so your IDE bus spends 1.5 of every 2 seconds jammed by the drive.
We have some bug reports for this from magicdev too.
Interesting - I suppose there is no better way to detect media in
optical drives than polling? IIRC some IDE optical drives emits a signal
on media change (so we don't have to poll; we just listen to that
signal) but this is not widely available (since most drives doesn't
comply with the MMC specs) just like the notification from eject buttons
is not widely available, correct?
Who controls the power saving policy; the drive firmware or the kernel?
Is the jamming of the IDE bus caused by a deficiency in the kernel or is
that just the true way of the IDE spec?
How does other operating systems handle this?
Cheers,
David
12:41 a.m.
On Thu, Nov 11, 2004 at 03:09:18PM -0500, David Zeuthen wrote:
Interesting - I suppose there is no better way to detect media in
optical drives than polling? IIRC some IDE optical drives emits a signal
on media change (so we don't have to poll; we just listen to that
signal) but this is not widely available (since most drives doesn't
comply with the MMC specs) just like the notification from eject buttons
is not widely available, correct?
Its not a notification - you have to poll. MMC just added the ability to
pull for pending eject and other MMC features. Its all only in later MMC
and highly optional
Who controls the power saving policy; the drive firmware or the
kernel?
Both.
Is the jamming of the IDE bus caused by a deficiency in the kernel or
is
that just the true way of the IDE spec?
Its the way IDE works
How does other operating systems handle this?
Windows seems to have multiple techniques so I guess they have whitelists,
blacklists and strategy routines dependant on MMC features. Eg if they can
poll button state they use that.
Alan
1:20 a.m.
On Thu, Nov 04, 2004 at 01:40:59PM -0500, Steffen Persvold wrote:
I noticed it when trying to start applications such as Evolution,
FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
Can you file a bug on that and include the identify data for the drives. My
guess would be haldaemon is polling the drives and that would muck up the
performance in some cases. However it shouldnt be polling too often
1:25 a.m.
On Thu, 2004-11-04 at 19:20 -0500, Alan Cox wrote:
On Thu, Nov 04, 2004 at 01:40:59PM -0500, Steffen Persvold wrote:
> I noticed it when trying to start applications such as Evolution,
> FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
Can you file a bug on that and include the identify data for the drives. My
guess would be haldaemon is polling the drives and that would muck up the
performance in some cases. However it shouldnt be polling too often
Alan,
I'd be happy to. I will also include /proc/ide/piix output.
Regards,
Steffen
1:26 a.m.
I'm having the same problem so please E-mail me the bug ID and I'll add
my drive info to your bug report.
Alan Cox wrote:
On Thu, Nov 04, 2004 at 01:40:59PM -0500, Steffen Persvold wrote:
>I noticed it when trying to start applications such as Evolution,
>FireFox, OpenOffice etc. but then I started testing it with hdparm -t :
Can you file a bug on that and include the identify data for the drives. My
guess would be haldaemon is polling the drives and that would muck up the
performance in some cases. However it shouldnt be polling too often
--
Greg Gulik http://www.gulik.org/greg/
greg @ gulik.org
1:58 a.m.
Thanks.
I have the same problem on a Dell 8100.
However performance is still VERY slow (compared to FC2) even with hald
killed off.
It's definitely disk since it runs fine once a program is loaded until
it needs to access disk again where it slows down horribly.
Steffen Persvold wrote:
On Thu, 2004-11-04 at 18:26 -0600, Gregory Gulik wrote:
>I'm having the same problem so please E-mail me the bug ID and I'll add
>my drive info to your bug report.
>
It is now filed as Bug #138148
Regards,
Steffen
--
Greg Gulik http://www.gulik.org/greg/
greg @ gulik.org
7131
days inactive
7138
days old
19 comments
5 participants
participants (5)
-
Alan Cox -
Arjan van de Ven -
David Zeuthen -
Gregory Gulik -
Steffen Persvold