From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoL3w-0002GK-TT for qemu-devel@nongnu.org; Fri, 01 May 2015 20:13:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoL3t-0001bt-Nz for qemu-devel@nongnu.org; Fri, 01 May 2015 20:13:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoL3t-0001bp-HD for qemu-devel@nongnu.org; Fri, 01 May 2015 20:13:41 -0400 Message-ID: <554416B2.50904@redhat.com> Date: Fri, 01 May 2015 20:13:38 -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. > > 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? :) > > Paolo > I wrote a loop to batch the ascii-hex conversion instead of letting printf do it; then ran some more very, very scientific tests: memset alone: real 0m10.888s user 0m9.303s sys 0m9.146s send-batching: real 0m6.541s user 0m5.027s sys 0m4.941s memset+batching+b64: real 0m3.675s user 0m2.582s sys 0m1.718s So it still seems as if the b64 batching is a strict improvement speed-wise. I'll send the non-b64 batching patch separately later, unless you have thoughts otherwise. --js