All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chentao(Boby)" <boby.chen@huawei.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Cc: dengguoqiang@huawei.com, meiwanlong@huawei.com,
	mu.muyang@huawei.com, Yanqiangjun <yanqiangjun@huawei.com>,
	liuyongan@huawei.com, huangzhichao@huawei.com,
	xen-devel@lists.xenproject.org,
	zhangmin <rudy.zhangmin@huawei.com>,
	wu.wubin@huawei.com
Subject: Re: xen-blkback unmap with network retansmission will cause a coredump
Date: Tue, 23 Sep 2014 21:27:50 +0800	[thread overview]
Message-ID: <54217556.7020002@huawei.com> (raw)
In-Reply-To: <541FF362.4070404@citrix.com>



On 2014/9/22 18:01, Roger Pau Monné wrote:
> El 20/09/14 a les 12.57, Chentao(Boby) ha escrit:
>> Hi konrad and roger,
>>
>>     When xen-blkback module executes unmap operation, and at the same time the skb of network retansmission uses this map page, it will cause a crash of hostos.
>> The crash stack of this problem is like below.
>> <ffffffff8041133e>{do_page_fault+0x38e}
>> <ffffffff8040d9e8>{page_fault+0x28}
>> <ffffffff80223cdb>{memcpy+0xb}
>> <ffffffff802325c2>{swiotlb_tbl_map_single+0x212}
>> <ffffffff8023274a>{swiotlb_map_page+0x17a}
>> <ffffffffa03468e6>{tg3:tg3_start_xmit+0x656}
>> <ffffffff80354d14>{dev_hard_start_xmit+0x334}
>> <ffffffff803721be>{sch_direct_xmit+0x1ae}
>>
>>     I search website, found citrix engineers has met this problem long time ago. And I realized citrix engineers solve this problem according to modify kernel stack.
>> Because this modification is very large, linux kernel community hasn't accept it until now. I have a immature thought, in dispatch_rw_block_io function, if this io
>> is a write operation, we use grant copy hypercall instead of grant map hypercall. I verify my modification and it can solve this problem.
>>
>>     What's your opinion of my modification? I am very looking forward to your reply. Any reply is appreciated.
> 
> Hello,
> 
> Yes, using grant-copy instead of grant-map is going to solve the
> problem, but it also defeats the purpose of persistent grants. I'm
> afraid it is going to introduce a noticeable performance penalty.
> 
Roger, you are right. We found 20%+ performance penalty in 1M 100% sequential write 128 depth

when workload is running on ramdisk.

> IMHO a better solution would be to use GNTTABOP_unmap_and_replace with
> the scratch balloon page instead of GNTTABOP_unmap_grant_ref. See
> arch/x86/xen/p2m.c m2p_remove_override for an example implementation of
> this procedure.
>
You mean if we replace GNTTABOP_unmap_grant_ref with GNTTABOP_unmap_and_replace in xen-blkback module,

that will solve the problem. Is my understanding right?

> Roger.
> .
> 

  reply	other threads:[~2014-09-23 13:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-20 10:57 xen-blkback unmap with network retansmission will cause a coredump Chentao(Boby)
2014-09-22 10:01 ` Roger Pau Monné
2014-09-23 13:27   ` Chentao(Boby) [this message]
2014-09-23 14:16     ` Roger Pau Monné
2014-09-22 10:11 ` David Vrabel
2014-09-23 13:36   ` Chentao(Boby)

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=54217556.7020002@huawei.com \
    --to=boby.chen@huawei.com \
    --cc=dengguoqiang@huawei.com \
    --cc=huangzhichao@huawei.com \
    --cc=konrad.wilk@oracle.com \
    --cc=liuyongan@huawei.com \
    --cc=meiwanlong@huawei.com \
    --cc=mu.muyang@huawei.com \
    --cc=roger.pau@citrix.com \
    --cc=rudy.zhangmin@huawei.com \
    --cc=wu.wubin@huawei.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yanqiangjun@huawei.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 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.