From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVI7o-0006p0-If for qemu-devel@nongnu.org; Tue, 10 Mar 2015 07:15:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVI7i-0007lQ-8m for qemu-devel@nongnu.org; Tue, 10 Mar 2015 07:15:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVI7i-0007kE-1R for qemu-devel@nongnu.org; Tue, 10 Mar 2015 07:14:54 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2ABEpaT030441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 10 Mar 2015 07:14:52 -0400 Message-ID: <54FED227.40100@redhat.com> Date: Tue, 10 Mar 2015 12:14:47 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1425973810-22831-1-git-send-email-famz@redhat.com> <1425973810-22831-2-git-send-email-famz@redhat.com> In-Reply-To: <1425973810-22831-2-git-send-email-famz@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/2] exec: Convert bounce buffer to a set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , qemu-devel@nongnu.org On 10/03/2015 08:50, Fam Zheng wrote: > + QLIST_ENTRY(BounceBuffer) next; Where is this used? > - if (buffer != bounce.buffer) { > + BounceBuffer *bounce; > + > + bounce = bounce_buffer_find_and_remove(buffer); > + if (!bounce) { I'm afraid that this adds a mutex lock/unlock pair and a hash table lookup on a very hot path. One possibility is to add a check that the hash table is not empty in bounce_buffer_find_and_remove. That can be done outside the lock so it's fast. I'm also wondering if it's okay to let the guest do arbitrarily large memory allocations (e.g. DMA from a huge unassigned memory area above guest RAM); effectively you're disabling the "/* Avoid unbounded allocations */" safety guard. Is it hard to do this while keeping map_clients? Paolo