On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote:

On 2019/1/7 上午11:28, Michael S. Tsirkin wrote:

quoted

On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote:

quoted

On 2019/1/3 上午4:47, Michael S. Tsirkin wrote:

quoted

On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote:

quoted

This series tries to access virtqueue metadata through kernel virtual
address instead of copy_user() friends since they had too much
overheads like checks, spec barriers or even hardware feature
toggling.

Will review, thanks!
One questions that comes to mind is whether it's all about bypassing
stac/clac.  Could you please include a performance comparison with
nosmap?

On machine without SMAP (Sandy Bridge):

Before: 4.8Mpps

After: 5.2Mpps

OK so would you say it's really unsafe versus safe accesses?
Or would you say it's just a better written code?

It's the effect of removing speculation barrier.

You mean __uaccess_begin_nospec introduced by
commit 304ec1b050310548db33063e567123fae8fd0301
?

So fundamentally we do access_ok checks when supplying
the memory table to the kernel thread, and we should
do the spec barrier there.

Then we can just create and use a variant of uaccess macros that does
not include the barrier?

Or, how about moving the barrier into access_ok?
This way repeated accesses with a single access_ok get a bit faster.
CC Dan Williams on this idea.

quoted

quoted

On machine with SMAP (Broadwell):

Before: 5.0Mpps

After: 6.1Mpps

No smap: 7.5Mpps


Thanks

no smap being before or after?

Let me clarify:


Before (SMAP on): 5.0Mpps

Before (SMAP off): 7.5Mpps

After (SMAP on): 6.1Mpps


Thanks

How about after + smap off?

And maybe we want a module option just for the vhost thread to keep smap
off generally since almost all it does is copy stuff from userspace into
kernel anyway. Because what above numbers should is that we really
really want a solution that isn't limited to just meta-data access,
and I really do not see how any such solution can not also be
used to make meta-data access fast.

-- 
MST