Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932999AbbBQNLr (ORCPT ); Tue, 17 Feb 2015 08:11:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52054 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756357AbbBQNLo (ORCPT ); Tue, 17 Feb 2015 08:11:44 -0500 Message-ID: <54E33E09.5090603@redhat.com> Date: Tue, 17 Feb 2015 14:11:37 +0100 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: Igor Mammedov , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] vhost: support upto 509 memory regions References: <1423842599-5174-1-git-send-email-imammedo@redhat.com> <20150217090242.GA20254@redhat.com> <54E31F24.1060705@redhat.com> <20150217123212.GA6362@redhat.com> In-Reply-To: <20150217123212.GA6362@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1715 Lines: 46 On 17/02/2015 13:32, Michael S. Tsirkin wrote: > On Tue, Feb 17, 2015 at 11:59:48AM +0100, Paolo Bonzini wrote: >> >> >> On 17/02/2015 10:02, Michael S. Tsirkin wrote: >>>> Increasing VHOST_MEMORY_MAX_NREGIONS from 65 to 509 >>>> to match KVM_USER_MEM_SLOTS fixes issue for vhost-net. >>>> >>>> Signed-off-by: Igor Mammedov >>> >>> This scares me a bit: each region is 32byte, we are talking >>> a 16K allocation that userspace can trigger. >> >> What's bad with a 16K allocation? > > It fails when memory is fragmented. If memory is _that_ fragmented I think you have much bigger problems than vhost. > I'm guessing kvm doesn't do memory scans on data path, vhost does. It does for MMIO memory-to-memory writes, but that's not a particularly fast path. KVM doesn't access the memory map on fast paths, but QEMU does, so I don't think it's beyond the expectations of the kernel. For example you can use a radix tree (not lib/radix-tree.c unfortunately), and cache GVA->HPA translations if it turns out that lookup has become a hot path. The addressing space of x86 is in practice 44 bits or fewer, and each slot will typically be at least 1 GiB, so you only have 14 bits to dispatch on. It's probably possible to only have two or three levels in the radix tree in the common case, and beat the linear scan real quick. The radix tree can be tuned to use order-0 allocations, and then your worries about fragmentation go away too. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/