From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypf5h-0007hw-QM for qemu-devel@nongnu.org; Tue, 05 May 2015 11:49:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypf5c-0007RZ-RK for qemu-devel@nongnu.org; Tue, 05 May 2015 11:49:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypf5c-0007Qb-Ke for qemu-devel@nongnu.org; Tue, 05 May 2015 11:48:56 -0400 Message-ID: <5548E664.4030903@redhat.com> Date: Tue, 05 May 2015 11:48:52 -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> <554416B2.50904@redhat.com> <55489D00.7050303@redhat.com> In-Reply-To: <55489D00.7050303@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/05/2015 06:35 AM, Paolo Bonzini wrote: > > > On 02/05/2015 02:13, John Snow wrote: >>> >> >> 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. > > Ok, this is more similar to what I'd expect (3.6 * 6 / 4 = 5.4, I'm not > sure if you have the memset optimization in the send-batching test). > I did, yes. Hence the "very, very scientific" warning. I just pushed patches down my stack and tested with each new optimization. Unoptimized is still ~14s. > Hex is obviously more debuggable compared to Base64 (unless you starred > in the Matrix movies), so I'm a bit undecided about this one. Anyone > can break the tie? > > Paolo > I specifically left things that alter control flow using hex nibbles -- such as the FIS packets, PRD tables, and all other existing tests. I only use the b64 encoding for raw data patterns, which don't really need to be debugged. Either they match or they don't: any particular values are uninteresting. Any future test can be switched to/from hex/b64 by just altering "mem{read,write}()" to "buf{read,write}()" as desired. I specifically opted not to alter *all* qtest IO for this very reason. Does that help? :) If you're not opposed to the rest of this series, I will send a v2 including the hex batching optimization. --js