On 05/05/2016 11:51 PM, Ming Lin wrote:
Hi Andy,
I'm looking at TCMU's performance.
Just played with tcmu-runner/file_example ...
I guess the poor performance comes from tcmu-runner/file_example.c.
I'll try to modify file_example.c to use AIO+DIO.
My goal is to verify whether tcmu's file handler can get similar
performance as iblock.
What do you think?
Hi Ming, thanks for taking a look!
I would say file_example.c is only worth tuning if it helps us improve
performance for non-example handlers -- like qcow, glfs, or any future
ones -- by showing ways that the common user or kernel TCMU code might
be improved. Nobody should ever use file_example handler in production,
it offers nothing over the kernel fileio backstore.
I would love for us to have a better understanding of the impact the
current code in target_core_user.c has on performance. Impact of the
ring size, context switches, how much batching of commands we're
getting, copy overhead -- these sort of things have not yet been
characterized with actual benchmarks[1].
That said, if you found using AIO+DIO in the file handler gave better
performance, then we might want to also have that code as an example for
handler writers in addition to what's there now. :)
Regards -- Andy
[1] well we have
http://opensource-storage.blogspot.co.nz/2016/04/using-lio-with-gluster.html
but that's giving us TCMU performance only in the context of a specific
handler, and versus FUSE...
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html