svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Alexander Motin]

On 25.08.2013 15:26, Andre Oppermann wrote:
> On 25.08.2013 14:12, Alexander Motin wrote:
>> On 25.08.2013 14:21, Alexander Motin wrote:
>>> Author: mav
>>> Date: Sun Aug 25 11:21:10 2013
>>> New Revision: 254846
>>> URL: http://svnweb.freebsd.org/changeset/base/254846
>>>
>>> Log:
>>>    Allow GEOM direct dispatch for zvol providers.  Skip request
>>> handover to
>>>    the worker thread if current context allows sleeping (thanks to
>>> the direct
>>>    dispatch in action we are not in GEOM thread).
>>>
>>>    Together this doubles zvol performance, reaching up to 300K IOPS
>>> on my tests.
>>>    If there would be unmapped I/O support for zvols, the above value
>>> could be
>>>    even bigger.
>>
>> I heavily underestimated effect of this change for the case of
>> uncached reads and probably
>> synchronous writes. Due to synchronous nature of the code, parallel
>> execution introduced by this
>> change can increase performance by much more then mentioned two times.
>> With 8-64 threads doing
>> uncached random read this change gives 6-10x performance!
>
> Any chance for this to make it into HEAD before API freeze?

GEOM direct dispatch code is still very experimental and this change is 
an integral part of it. If there would be month or two ahead before 
slush, I would say there is a chance to merge both CAM and GEOM changes. 
But we are already in code slush state, so I doubt, unless I would be 
gives some official carte blanche and active help in code review and 
testing. While I think CAM locking changes are quite complete already, I 
still got no any real reviews for them 10 days after posting to the 
lists. :(

GEOM changes I've done so far are quite small and are not breaking any 
KPI/KBI, only extending them, so they probably could be merged to 
10-STABLE at any point later. CAM changes are much bigger and more 
invasive, but mostly for CAM internals. I haven't checked explicitly, 
but I hope that binary controller drivers compatibility should not be 
broken, so hopefully it also could be merged too.

>> Now I am very curios why zvol was made to have only one worker thread
>> per zvol, while multiple
>> threads there could give major improvement even without direct dispatch.

Simple introduction of multiple worker threads to zvol could also help a 
lot for case of synchronous I/O. Somewhat less then direct dispatch, but 
that would be smaller and independent change.

-- 
Alexander Motin