From: David Vrabel <david.vrabel@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Boris.Ostrovsky@oracle.com, xen-devel@lists.xensource.com,
"xen.org" <Ian.Jackson@eu.citrix.com>
Subject: Re: [linux-linus test] 25478: regressions - FAIL
Date: Mon, 17 Mar 2014 12:01:18 +0000 [thread overview]
Message-ID: <5326E40E.2000600@citrix.com> (raw)
In-Reply-To: <1394816855.6442.168.camel@kazak.uk.xensource.com>
On 14/03/14 17:07, Ian Campbell wrote:
> On Fri, 2014-03-14 at 16:42 +0000, xen.org wrote:
>> flight 25478 linux-linus real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/25478/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 12557
>
> Is anyone looking at these? Apparently this hasn't passed for 23 months:
> http://xenbits.xen.org/gitweb/?p=linux-pvops.git;a=shortlog;h=refs/heads/tested/linux-linus
>
> Looking through the recent failures this migration one seems quite
> common but there seem to be a few others, search for "[linux-linux
> test]" in http://lists.xen.org/archives/html/xen-devel/2014-03/ for some
> examples.
skb compound pages result in too much SWIOTLB usage. In XenServer we
have the following to disable it.
net/core: Order-3 frag allocator causes SWIOTLB bouncing under Xen
From: Zoltan Kiss <zoltan.kiss@citrix.com>
THIS PATCH IS NOT INTENDED TO BE UPSTREAMED, IT HAS ONLY INFORMING PURPOSES!
I've noticed a performance regression with upstream kernels when used as
Dom0
under Xen. The classic kernel can utilize the whole bandwidth of a 10G NIC
(ca. 9.3 Gbps), but upstream can reach only ca. 7 Gbps. I found that it
happens because SWIOTLB has to do double buffering. The per task frag
allocator introduced in 5640f7 creates 32 kb frags, which are not contiguous
in mfn space.
This patch provides a workaround by going back to the old way. The possible
ideas came up to solve this:
* make sure Dom0 memory is contiguous: it sounds trivial, but doesn't
work with
driver domains, and there are lots of situations where this is not possible.
* use PVH Dom0: so we will have IOMMU. In the future sometime.
* use IOMMU with PV Dom0: this seems to happen earlier.
Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
diff --git a/net/core/sock.c b/net/core/sock.c
index d6d024c..44614a5 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1791,7 +1791,7 @@ struct sk_buff *sock_alloc_send_skb(struct sock
*sk, unsigned long size,
EXPORT_SYMBOL(sock_alloc_send_skb);
/* On 32bit arches, an skb frag is limited to 2^15 */
-#define SKB_FRAG_PAGE_ORDER get_order(32768)
+#define SKB_FRAG_PAGE_ORDER get_order(4096)
bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
{
next prev parent reply other threads:[~2014-03-17 12:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-27 18:00 [linux-linus test] 25677: regressions - FAIL xen.org
2014-03-14 16:42 ` [linux-linus test] 25478: " xen.org
2014-03-14 17:07 ` Ian Campbell
2014-03-14 18:23 ` Konrad Rzeszutek Wilk
2014-03-17 11:08 ` Ian Campbell
2014-03-17 19:36 ` Konrad Rzeszutek Wilk
2014-03-18 9:28 ` Ian Campbell
2014-03-18 9:43 ` Ian Campbell
2014-03-18 9:29 ` Ian Campbell
2014-03-18 10:55 ` David Vrabel
2014-03-18 11:04 ` Ian Campbell
2014-03-18 11:10 ` Ian Campbell
2014-03-18 11:25 ` David Vrabel
2014-03-18 11:29 ` Ian Campbell
[not found] ` <53283118.5050706@citrix.com>
[not found] ` <1395143026.12847.47.camel@kazak.uk.xensource.com>
2014-04-10 15:37 ` [linux-linus test] 25478: regressions - FAIL [and 1 more messages] Ian Jackson
2014-04-16 10:12 ` Ian Jackson
2014-04-16 10:53 ` David Vrabel
2014-04-16 11:47 ` Ian Jackson
2014-04-16 13:48 ` David Vrabel
2014-03-17 12:01 ` David Vrabel [this message]
2014-03-17 12:23 ` [linux-linus test] 25478: regressions - FAIL Ian Campbell
2014-03-17 19:38 ` Konrad Rzeszutek Wilk
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=5326E40E.2000600@citrix.com \
--to=david.vrabel@citrix.com \
--cc=Boris.Ostrovsky@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).