Opened 11 years ago
Closed 6 years 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: | ||
| 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)
Change History (6)
follow-up: 2 comment:1 by , 11 years ago
follow-up: 3 comment:2 by , 11 years ago
| Cc: | 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?
follow-up: 4 comment:3 by , 11 years ago
comment:4 by , 11 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.
comment:5 by , 6 years ago
| Resolution: | → not reproducible |
|---|---|
| Status: | new → closed |
Closing since:
- I don't have that machine anymore
- Performance seems much better lately, even on VMs
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.