From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
stefano.stabellini@eu.citrix.com, linux-kernel@vger.kernel.org,
david.vrabel@citrix.com, boris.ostrovsky@oracle.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux
Date: Mon, 14 Sep 2015 14:08:44 +0200 [thread overview]
Message-ID: <55F6B8CC.5090406__41455.2915412516$1442232642$gmane$org@citrix.com> (raw)
In-Reply-To: <55F6ADAE.1010609@citrix.com>
El 14/09/15 a les 13.21, Julien Grall ha escrit:
> On 14/09/15 12:04, Roger Pau Monné wrote:
>> Hello,
>>
>> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>>> Hi Roger,
>>>
>>> On 14/09/15 09:56, Roger Pau Monné wrote:
>>>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>>>>> Hi all,
>>>>>
>>>>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>>>>> hypercall interface and PV protocol are always based on 4KB page granularity.
>>>>>
>>>>> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
>>>>> guest crash.
>>>>>
>>>>> This series is a first attempt to allow those Linux running with the current
>>>>> hypercall interface and PV protocol.
>>>>>
>>>>> This solution has been chosen because we want to run Linux 64KB in released
>>>>> Xen ARM version or/and platform using an old version of Linux DOM0.
>>>>>
>>>>> There is room for improvement, such as support of 64KB grant, modification
>>>>> of PV protocol to support different page size... They will be explored in a
>>>>> separate patch series later.
>>>>>
>>>>> TODO list:
>>>>> - Convert swiotlb to 64KB
>>>>> - Convert xenfb to 64KB
>>>>> - Support for multiple page ring support
>>>>> - Support for 64KB in gnttdev
>>>>> - Support of non-indirect grant with 64KB frontend
>>>>> - It may be possible to move some common define between
>>>>> netback/netfront and blkfront/blkback in an header
>>>>>
>>>>> I've got most of the patches for the TODO items. I'm planning to send them as
>>>>> a follow-up as it's not a requirement for a basic guests.
>>>>>
>>>>> All patches has been built tested for ARM32, ARM64, x86. But I haven't tested
>>>>> to run it on x86 as I don't have a box with Xen x86 running. I would be
>>>>> happy if someone give a try and see possible regression for x86.
>>>>
>>>> Do you have figures regarding if/how much performance penalty do the
>>>> blkfront/blkback patches add to the traditional 4KB scenario (frontend
>>>> and backend running on guests using 4KB pages)?
>>>
>>> Which benchmark do you advice? Although, I don't have SSD on this
>>> platform so it may be possible that the bottleneck will be the hard drive.
>>
>> I've normally used a ramdisk in order to test performance, but it seems
>> nullblk would be a better option (it wasn't available before) and it
>> doesn't reduce the size of RAM available to the system:
>>
>> https://www.kernel.org/doc/Documentation/block/null_blk.txt
>
> I will give a look to this.
>
>>>>
>>>> Since there's been no design document about this and the TODO list
>>>> doesn't contain it, I would like to know which plans do we have in order
>>>> to fix this properly.
>>>
>>> Can you explain what kind of design document you were expecting? The
>>> support of 64KB page granularity is pretty straight-forward and there is
>>> not many way to do it. We have to split the page in 4KB chunk to feed
>>> the ring.
>>
>> I was thinking about adding support for 64KB grants with the aim of
>> eventually removing the splitting done in xen-blkfront and the
>> grant-table code in general.
>
> I'd like to see a basic support of 64KB page granularity upstream before
> starting to think about performance improvement. And there is still a
> lot to do.
I wasn't actually thinking of this as a performance improvement, but
rather as a way of fixing this properly and removing the complexity
added to xen-blkfront, thus providing a PV block protocol that natively
supports 64KB pages. This would be like hardware components already do
AFAIK, because I don't think there are other drivers in the Linux tree
that do this kind of splitting.
> Although, having 64KB grants won't remove the splitting as we would
> still have to support frontend/backend which only handle 4KB grant.
IMHO, given enough time I would just drop those.
>>> 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.
>
> I will only be able to give percentage. I guess this would be sufficient
> for you?
Well, absolute numbers together with the standard deviation are IMHO the
best way to provide those figures (ie: see ministat(1) output for
example), but percentages should also be fine.
I'm just interested in knowing the performance difference between having
this patches applied or not when using 4KB pages on the frontend and the
backend.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-09-14 12:08 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 15:33 [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 01/20] net/xen-netback: xenvif_gop_frag_copy: move GSO check out of the loop Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 02/20] arm/xen: Drop pte_mfn and mfn_pte Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 03/20] xen: Add Xen specific page definition Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 04/20] xen/grant: Introduce helpers to split a page into grant Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 05/20] xen/grant: Add helper gnttab_page_grant_foreign_access_ref_one Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 06/20] block/xen-blkfront: Split blkif_queue_request in 2 Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 07/20] block/xen-blkfront: Store a page rather a pfn in the grant structure Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 08/20] block/xen-blkfront: split get_grant in 2 Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 09/20] xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB pages Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 10/20] xen/xenbus: Use Xen page definition Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 11/20] tty/hvc: xen: Use xen " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 12/20] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 16:39 ` Stefano Stabellini
2015-09-07 16:39 ` Stefano Stabellini
2015-09-07 16:39 ` Stefano Stabellini
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 13/20] xen/events: fifo: Make it running on 64KB granularity Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 14/20] xen/grant-table: " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 15/20] block/xen-blkfront: Make it running on 64KB page granularity Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 16/20] block/xen-blkback: " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 17/20] net/xen-netfront: " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 18/20] net/xen-netback: " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 16:57 ` Wei Liu
2015-09-07 16:57 ` Wei Liu
2015-09-07 16:57 ` Wei Liu
2015-09-08 11:07 ` Julien Grall
2015-09-08 11:07 ` [Xen-devel] " Julien Grall
2015-09-08 11:07 ` Julien Grall
2015-09-08 11:09 ` Wei Liu
2015-09-08 11:09 ` [Xen-devel] " Wei Liu
2015-09-08 11:09 ` Wei Liu
2015-09-07 15:33 ` [PATCH v4 19/20] xen/privcmd: Add support for Linux " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` [PATCH v4 20/20] arm/xen: Add support for " Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-07 15:33 ` Julien Grall
2015-09-11 19:39 ` [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux Julien Grall
2015-09-11 19:39 ` Julien Grall
2015-09-11 19:39 ` Julien Grall
2015-09-14 8:56 ` Roger Pau Monné
2015-09-14 8:56 ` Roger Pau Monné
2015-09-14 8:56 ` Roger Pau Monné
2015-09-14 10:40 ` Julien Grall
2015-09-14 10:40 ` Julien Grall
2015-09-14 10:40 ` Julien Grall
2015-09-14 11:04 ` Roger Pau Monné
2015-09-14 11:04 ` Roger Pau Monné
2015-09-14 11:21 ` Julien Grall
2015-09-14 11:21 ` Julien Grall
2015-09-14 11:21 ` Julien Grall
2015-09-14 12:08 ` Roger Pau Monné
2015-09-14 12:08 ` Roger Pau Monné
2015-09-14 12:47 ` Julien Grall
2015-09-14 12:47 ` Julien Grall
2015-09-14 14:29 ` Roger Pau Monné
2015-09-14 14:29 ` Roger Pau Monné
2015-09-14 14:29 ` Roger Pau Monné
2015-09-14 14:46 ` Julien Grall
2015-09-14 14:46 ` Julien Grall
2015-09-14 14:46 ` Julien Grall
2015-09-14 14:54 ` Stefano Stabellini
2015-09-14 14:54 ` Stefano Stabellini
2015-09-14 15:23 ` Roger Pau Monné
2015-09-14 15:23 ` Roger Pau Monné
2015-09-22 10:59 ` Ian Campbell
2015-09-22 10:59 ` Ian Campbell
2015-09-22 10:59 ` Ian Campbell
2015-10-06 9:28 ` Roger Pau Monné
2015-10-06 9:28 ` Roger Pau Monné
2015-10-06 10:17 ` Ian Campbell
2015-10-06 10:17 ` Ian Campbell
2015-10-06 10:17 ` Ian Campbell
2015-10-06 13:55 ` Stefano Stabellini
2015-10-06 13:55 ` Stefano Stabellini
2015-10-06 13:55 ` Stefano Stabellini
2015-10-06 9:28 ` Roger Pau Monné
2015-09-14 15:23 ` Roger Pau Monné
2015-09-14 14:54 ` Stefano Stabellini
2015-09-14 12:47 ` Julien Grall
2015-09-18 14:10 ` Julien Grall
2015-09-18 14:10 ` Julien Grall
2015-09-18 14:10 ` Julien Grall
2015-09-14 12:08 ` Roger Pau Monné [this message]
2015-09-14 11:32 ` Arnd Bergmann
2015-09-14 11:32 ` Arnd Bergmann
2015-09-15 13:14 ` [Xen-devel] " David Vrabel
2015-09-15 13:14 ` David Vrabel
2015-09-15 13:24 ` Arnd Bergmann
2015-09-15 13:24 ` [Xen-devel] " Arnd Bergmann
2015-09-15 13:24 ` Arnd Bergmann
2015-09-15 13:14 ` David Vrabel
2015-09-14 11:32 ` Arnd Bergmann
2015-09-14 11:04 ` Roger Pau Monné
2015-09-29 16:27 ` [Xen-devel] " David Vrabel
2015-09-29 16:27 ` David Vrabel
2015-09-29 16:33 ` Julien Grall
2015-09-29 16:33 ` Julien Grall
2015-09-29 16:36 ` David Vrabel
2015-09-29 16:36 ` [Xen-devel] " David Vrabel
2015-09-29 16:36 ` David Vrabel
2015-09-29 16:33 ` Julien Grall
2015-09-29 16:27 ` David Vrabel
-- strict thread matches above, loose matches on Subject: below --
2015-09-07 15:33 Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='55F6B8CC.5090406__41455.2915412516$1442232642$gmane$org@citrix.com' \
--to=roger.pau@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.