2017-02-10 18:39 GMT+08:00 David Gwynne <da...@gwynne.id.au>:
> > 2017-02-09 16:41 GMT+08:00 David Gwynne <da...@gwynne.id.au>:
>
..
> i can go into more detail if you want.
>
> cheers,
> dlg
>
Hi David,
Thank you - yes please go into more detail!
Also on a more concrete level I would be the most curious to understand how
far away we would be from having concurrent IO access (e.g. on various
distances from the hardware: via some lowlevel block device API that would
be mp-safe / via open("/dev/rsd0c") + read() that would be mp-safe / that
the filesystem would be mp-safe so open("myfile") + read() would be all
concurrent)?
Then, just to get an idea of what's going on, regarding how the system is
doing concurrent IO, or how you like to call it: While I had a
pre-understanding that the kernel's big lock could be playing in so that it
would be a performance constraint, the people I talked to seemed to suggest
that the kernel is doing IO in a procedure-call-based code-blocking,
synchronous way today, which only runs one command in the sata comand queue
concurrently, and so I got an impression that concurrency-friendly IO and
higher IOPS would require a reconstruction of the IO system where IO
operations are represented internally rather by data structures run by an
asynchronous mechanism. How is it actually, and where is it going?
Regarding mp-safe drivers, I would guess ahci.4 and nvme.4 are the most
commonly used interfaces for SSD:s.
Best regards,
Mikael
