Bump
2017-02-10 22:11 GMT+08:00 Mikael <mikael.ml...@gmail.com>:
> 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
