From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH for 4.7] xen: Replace alloc_vcpu_guest_context() with vmalloc() Date: Fri, 21 Aug 2015 19:10:51 +0100 Message-ID: <55D769AB.2060609@citrix.com> References: <1440179506-478-1-git-send-email-andrew.cooper3@citrix.com> <20150821175546.GC26425@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150821175546.GC26425@l.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Ian Campbell , Tim Deegan , Xen-devel , Stefano Stabellini , Jan Beulich , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 21/08/15 18:55, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 21, 2015 at 06:51:46PM +0100, Andrew Cooper wrote: >> This essentially reverts c/s 2037f2adb "x86: introduce >> alloc_vcpu_guest_context()", including the newer arm bits, but achieves >> the same end goal by using the newer vmalloc() infrastructure. > Could you explain what this fixes? Or perhaps with an explanation > of why this will make Xen [ ]better; [ ] faster [ ] magical. > > :-) Ain't the diffstat enough to qualify for [x]better ;) ? > > > Thanks. It is relevant to a patch of Rogers which I am reviewing from the no-DM series. I was writing in reply to that, but this can also do. alloc_vcpu_guest_context() was introduced long before vmalloc(), and attempts to make the same end result using per-pcpu fixmap entries, which scale by the compile-time NR_CPUS. This patch causes a net reduction in compiled size for each arch (small for ARM, larger for x86) and removes a scalability limit for compiling with large numbers of cpus. I think I can guess what you are going to ask me to do, given this explanation. ~Andrew