Improving Harddisk Performance for Concurrent Disk-Operations
Nordlöw
dramatically, say 5-10 times, when two or more processes try to access
the same harddisk (arm) "concurrently". This is, IMHO, a truly
unacceptable "desktop-performance bug". Is this related to the
granularity of the linux kernel scheduler, or is it difficult to solve
because the harddisk operations interface (read/write) is too low-
level and in conflict with the requirement that each disk-operation
should finish as quickly as posibble?
I have read somewhere that firefox mysql had a similar performance
problem related to the fsync system call that was "adjusted" in some
recent kernel version.
I guess it boils to that the system commands read() and write() ought
to have an additional argument, say "prio" or "deadline", kind of like
RTOS processes have, right? Then the kernel can make better use of
data-locality when writing large files. Is there a kernel or disk
mount setting for such a deadline?
Does any virtual file system such, as gvfs/gio, try to solve this
issue by specifying these prios/max-delays to make coarser time-
sharing of these concurrent disk-operations?
And finally: Will all these problems go away when the world switches
to solid state drives (SSD) that typically have 100 to 1000 times
lower (random) access time?
Thanks in advance,
Per Nordlöw
David Schwartz
> I have noticed that, in Ubuntu, the harddisk performance drops
> dramatically, say 5-10 times, when two or more processes try to access
> the same harddisk (arm) "concurrently".
Yep.
> This is, IMHO, a truly
> unacceptable "desktop-performance bug". Is this related to the
> granularity of the linux kernel scheduler,
No.
> or is it difficult to solve
> because the harddisk operations interface (read/write) is too low-
> level and in conflict with the requirement that each disk-operation
> should finish as quickly as posibble?
No.
It's a fundamental fact of the way the hardware works that your read
throughput is going to be a lot slower if you try to read from two
different areas of the disk at the same time.
> I have read somewhere that firefox mysql had a similar performance
> problem related to the fsync system call that was "adjusted" in some
> recent kernel version.
>
> I guess it boils to that the system commands read() and write() ought
> to have an additional argument, say "prio" or "deadline", kind of like
> RTOS processes have, right? Then the kernel can make better use of
> data-locality when writing large files. Is there a kernel or disk
> mount setting for such a deadline?
I'm not sure a priority option would help much. If you delay "bulk"
reads/writes, it just means they'll cause longer delays when you
finally process them (since more data will be backed up).
> Does any virtual file system such, as gvfs/gio, try to solve this
> issue by specifying these prios/max-delays to make coarser time-
> sharing of these concurrent disk-operations?
You can change I/O schedulers on Linux and you can tune individual
devices.
http://www.wlug.org.nz/LinuxIoScheduler
> And finally: Will all these problems go away when the world switches
> to solid state drives (SSD) that typically have 100 to 1000 times
> lower (random) access time?
If we change to devices with much random access times closer to their
sequential access times, the problem will be significantly lessened.
However, today's SSDs also have huge difference between their
sequential access throughput and their random access throughput. So
the problem is not going to go away unless that changes too.
DS