From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755076AbbINLcg (ORCPT ); Mon, 14 Sep 2015 07:32:36 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:61890 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751626AbbINLcf convert rfc822-to-8bit (ORCPT ); Mon, 14 Sep 2015 07:32:35 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Julien Grall , xen-devel@lists.xenproject.org, wei.liu2@citrix.com, ian.campbell@citrix.com, konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org, david.vrabel@citrix.com, boris.ostrovsky@oracle.com Subject: Re: [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux Date: Mon, 14 Sep 2015 13:32:27 +0200 Message-ID: <2415578.qstFX0Ux2G@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <55F6A9DB.8040503@citrix.com> References: <1441640038-23615-1-git-send-email-julien.grall@citrix.com> <55F6A437.3040403@citrix.com> <55F6A9DB.8040503@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" X-Provags-ID: V03:K0:mGHmlMKofMW91YveDDUI6BjVbmSkKCOnTNVhHJtVvw0UiloMh5z cE++kqbVN0dfFUp4gN4EAALDoTavwzQgkrsParUdFUCntzjdTDlHLbBXwzJeHK+MSt4qaoH LtsDFoqWQh+43ZYrxlpNp7xOjW171w9+UAgIb6MDC5d03bpgx56rKq6iujRhSjBjkBT7VRA tsIc7vOrltjB1cCA1ZSGw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SPYaGrb339M=:WMtxT61CjGldf0QmTQgkT3 6bna6iDYkV4R8ERoQYt1PYELOiWjVeQ8jbh6Syhp05bDKWveCUCc6rqk7trJQNkE/2iP3z0uA 9pZf2HjQhw/qlH0RR4P6Dhsh0JG3VVnCVQgjKtWBmZki40OfkxqAhRv29VzHqzv0HGAY6c62+ Q1Cf49uIbE4LC36R43dyPAVCDHK16fpmgUu9XXA298BCQfyXs++10/N8M601p7d1iUDjBdFbB 8i4Arf/LTIENg9EMgBGDIV89PS6MDE/FPnzdTCJP3aYcbLkDNCza+Kv6MVxpDlaBlbgblpRQj mLRuB8CNHRMLOjg6mzYdriQdF/yvatFnQ1zie9OZxUj4zVgOFB9fu3wxOVp9bxkNnvtRYlxI6 /M19/R0QpjEnPBnl3hh2Y9AljqNWSPFVJvDjuSaGMVdO4kdbq9uVG9/xkJpL8/D9sXucsDd2S GCiAGaxz4v65ZNfWKK0QJbX/m72xZhpLA8MwUh43Yf0r+xMxZwcLR6qhBpPS0isoiR48aZEiI PC1rVWlBK8h9sS2wfN+LSdYOdBWDnuAsmo1my4TbfmzQrrf267aQ48GGAMwODb6EBXjHY6WKm 1NtQwJnOZREQauRwrXrB25kBRmEbXUhW90vW3YQzYW0d2Jk2pUm29JrVhLGkzhtk/QP7eCI8g x1ZwWEeNjCAuXhr0cYFyecXKcNBWkLiRozJLerdNMIO+nywlNTuzCznINFR4mPmAjW5tPimjE HT/RWDyL+MO9/0Og Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 14 September 2015 13:04:59 Roger Pau Monné wrote: > > TBH, I'm expecting a small impact to the performance. It would be hard > > to get the exactly the same performance as today if we keep the helpers > > to avoid the backend dealing himself with the splitting and page > > granularity. > > > > Although, if the performance impact is not acceptable, it may be > > possible to optimize gnttab_foreach_grant_in_range by moving the > > function inline. The current way to the loop is the fastest I've found > > (I've wrote a small program to test different way) and we will need it > > when different of size will be supported. > > I don't expect the performance to drop massively with this patches > applied, but it would be good to al least have an idea of the impact. Note that using 64kb pages in Linux tends to destroy performance in Linux in any case, as the memory consumption for most workloads explodes. In a virtualized environment you already tend to be memory constrained, so any measurement should take that into account and put the extra overhead into perspective to the massive overhead of running 64kb pages when RAM is tight. Arnd