From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752920Ab1HAJSP (ORCPT ); Mon, 1 Aug 2011 05:18:15 -0400 Received: from mail-gw0-f46.google.com ([74.125.83.46]:58505 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256Ab1HAJSK (ORCPT ); Mon, 1 Aug 2011 05:18:10 -0400 Message-ID: <4E366F4A.1030704@gmail.com> Date: Mon, 01 Aug 2011 17:18:02 +0800 From: Liu Yuan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Avi Kivity CC: Sasha Levin , Stefan Hajnoczi , "Michael S. Tsirkin" , Rusty Russell , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Khoa Huynh , Badari Pulavarty , Christoph Hellwig Subject: Re: [RFC PATCH]vhost-blk: In-kernel accelerator for virtio block device References: <1311863346-4338-1-git-send-email-namei.unix@gmail.com> <4E325F98.5090308@gmail.com> <4E32A105.6080509@gmail.com> <1311953104.30835.15.camel@lappy> <4E36612F.6040809@redhat.com> In-Reply-To: <4E36612F.6040809@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/01/2011 04:17 PM, Avi Kivity wrote: > On 07/29/2011 06:25 PM, Sasha Levin wrote: >> On Fri, 2011-07-29 at 20:01 +0800, Liu Yuan wrote: >> > Looking at this long list,most are function pointers that can not be >> > inlined, and the internal data structures used by these functions are >> > dozons. Leave aside code complexity, this long code path would really >> > need retrofit. As Christoph simply put, this kind of mess is inherent >> > all over the qemu code. So I am afraid, the 'retrofit' would end >> up to >> > be a re-write the entire (sub)system. I have to admit that, I am >> > inclined to the MST's vhost approach, that write a new subsystem >> other >> > than tedious profiling and fixing, that would possibly goes as far as >> > actually re-writing it. >> >> I don't think the fix for problematic userspace is to write more kernel >> code. >> >> vhost-net improved throughput and latency by several factors, allowing >> to achieve much more than was possible at userspace alone. >> >> With vhost-blk we see an improvement of ~15% - which I assume by your >> and Christoph's comments can be mostly attributed to QEMU. Merging a >> module which won't improve performance dramatically compared to what is >> possible to achieve in userspace (even if it would require a code >> rewrite) sounds a bit wrong to me > > Agree. vhost-net works around the lack of async zero copy networking > interface. Block I/O on the other hand does have such an interface, > and in addition transaction rates are usually lower. All we're saving > is the syscall overhead. > Personally I too agree with Sasha Levin. But vhost-blk is the first fast prototype that is supposed to act as a code base to do further optimisation, which I plan to utilize kernel's internal stuff like BIO layer, that can not be accessed from user space, to maximize the performance for raw disk based block IO. Yuan