From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoI7B-0005hn-9i for qemu-devel@nongnu.org; Fri, 01 May 2015 17:04:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoI76-0000Nc-89 for qemu-devel@nongnu.org; Fri, 01 May 2015 17:04:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoI76-0000NT-2U for qemu-devel@nongnu.org; Fri, 01 May 2015 17:04:48 -0400 Message-ID: <5543EA6E.5020804@redhat.com> Date: Fri, 01 May 2015 17:04:46 -0400 From: John Snow MIME-Version: 1.0 References: <1430510112-30474-1-git-send-email-jsnow@redhat.com> <1430510112-30474-5-git-send-email-jsnow@redhat.com> <5543E688.6020703@redhat.com> In-Reply-To: <5543E688.6020703@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 4/4] libqos/ahci: Swap memread/write with bufread/write List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: marc.mari.barcelo@gmail.com, afaerber@suse.de, stefanha@redhat.com On 05/01/2015 04:48 PM, Paolo Bonzini wrote: > > > On 01/05/2015 21:55, John Snow wrote: >> Where it makes sense, use the new faster primitives. >> For generally small reads/writes such as for the PRDT >> and FIS packets, stick with the more wasteful but >> easier to debug memread/memwrite. >> >> For ahci-test; >> With this patch: >> real 0m4.802s >> user 0m3.506s >> sys 0m2.393s >> >> Without this series: >> real 0m14.171s >> user 0m12.072s >> sys 0m12.527s > > The overhead of memread is 2, the overhead of base64 is 1.33, also > base64 should have a larger cost of computing each byte. It doesn't add up. > Right, there's more at play here than just the wire length. > Could it be simply that calling qtest_send (and hence > vsnprintf+qemu_chr_fe_write_all, neither of which are speed demons) once > per byte is hideously inefficient? :) > I can batch those too in another patch, or should I consider this a NACK? > Paolo > --js