Matthew Wilcox <willy@xxxxxxxxxxxxx> writes:
> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote:
>> I'm going to submit this version formally. If you're interested in
>> converting the ioctx_table to xarray, you can do that separately from a
>> security fix. I would include a performance analysis with that patch,
>> though. The idea of using a radix tree for the ioctx table was
>> discarded due to performance reasons--see commit db446a08c23d5 ("aio:
>> convert the ioctx list to table lookup v3"). I suspect using the xarray
>> will perform similarly.
>
> There's a big difference between Octavian's patch and mine. That patch
> indexed into the radix tree by 'ctx_id' directly, which was pretty
> much guaranteed to exhibit some close-to-worst-case behaviour from the
> radix tree due to IDs being sparsely assigned. My patch uses the ring
> ID which _we_ assigned, and so is nicely behaved, being usually a very
> small integer.
OK, good to know. I obviously didn't look too closely at the two.
> What performance analysis would you find compelling? Octavian's original
> fio script:
>
>> rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
>> blocksize=1024; numjobs=512; thread; loops=100
>>
>> on an EXT2 filesystem mounted on top of a ramdisk
>
> or something else?
I think the most common use case is a small number of ioctx-s, so I'd
like to see that use case not regress (that should be easy, right?).
Kent, what were the tests you were using when doing this work? Jens,
since you're doing performance work in this area now, are there any
particular test cases you care about?
Cheers,
Jeff
