Opened 6 years ago

Closed 14 months ago

#9628 closed bug (not reproducible)

Really bad disk performance / cache behaviour

Reported by: jackburton Owned by: nobody
Priority: normal Milestone: R1
Component: System Version: R1/Development
Keywords: Cc: mmlr
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

I've started using Haiku lately (to develop BeScreenCapture), and I found it really bad regarding disk read/write performance. Actually it could be a problem of cache behaviour. This is what happens: when I open a small file with PE, it takes some time to open, and during that time, the disk spins like crazy. Same thing when I save the file. Moreover, sometimes the disk spins like crazy also when I open the deskbar menu, or when I click "Start Capture" in BeScreenCapture (an operation which does not involve the disk at all, or in minimum part, at least). Note that the same machine (Intel T5550 processor, 4GB RAM) runs Ubuntu 12.04 just fine. The Haiku partition is 4GB, swap is around 200MB (but I tried with 1GB of swap as well). Note that lately (but could be two years, actually), Haiku on VirtualBox or qemu is practically unusable on this very machine, while I remember it used to be much better.

Attachments (1)

listdev.txt (3.0 KB ) - added by jackburton 6 years ago.
Output of listdev

Download all attachments as: .zip

Change History (6)

comment:1 by anevilyak, 6 years ago

Don't suppose you could post a listdev and sys log from that machine? Sounds quite likely to be hardware/driver specific. I've never seen behavior like that here at least, across multiple machines.

in reply to:  1 ; comment:2 by diver, 6 years ago

Cc: mmlr added

Note that lately (but could be two years, actually), Haiku on VirtualBox or qemu is practically unusable on this very machine, while I remember it used to be much better.

This is because some additional tracing has been added last year.

#define KDEBUG_LEVEL 0 in kernel_debug_config.h fixes it. Would be nice to know which exact revision introduced this slowness. Michael?

in reply to:  2 ; comment:3 by jackburton, 6 years ago

Replying to diver:

This is because some additional tracing has been added last year.

#define KDEBUG_LEVEL 0 in kernel_debug_config.h fixes it. Would be nice to know which exact revision introduced this slowness. Michael?

Indeed, that works. I guess this should be closed as invalid, then ?

in reply to:  3 comment:4 by jackburton, 6 years ago

Replying to jackburton:

Replying to diver:

This is because some additional tracing has been added last year.

#define KDEBUG_LEVEL 0 in kernel_debug_config.h fixes it. Would be nice to know which exact revision introduced this slowness. Michael?

Indeed, that works. I guess this should be closed as invalid, then ?

Except not really. Experiencing more or less the same problems. I'm attaching the output of listdev. Will post a captured clip of the long save time as soon as I fix BeScreenCapture again.

by jackburton, 6 years ago

Attachment: listdev.txt added

Output of listdev

comment:5 by jackburton, 14 months ago

Resolution: not reproducible
Status: newclosed

Closing since:

  • I don't have that machine anymore
  • Performance seems much better lately, even on VMs
Note: See TracTickets for help on using tickets.