Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.

["Wang, Xiaoming" <xiaoming.wang@xxxxxxxxx>]

Dear Wilk:

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Thursday, February 12, 2015 4:49 AM
> To: Wang, Xiaoming
> Cc: David Vrabel; linux-mips@xxxxxxxxxxxxxx; pebolle@xxxxxxxxxx; Zhang,
> Dongxing; lauraa@xxxxxxxxxxxxxx; d.kasatkin@xxxxxxxxxxx;
> heiko.carstens@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; ralf@linux-
> mips.org; chris@xxxxxxxxxxxxxxxxxx; takahiro.akashi@xxxxxxxxxx;
> linux@xxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> boris.ostrovsky@xxxxxxxxxx; Liu, Chuansheng; akpm@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to
> io_tlb_segsize configurable as flexible requirement about SW-IOMMU.
> 
> On Wed, Feb 11, 2015 at 08:38:29AM +0000, Wang, Xiaoming wrote:
> > Dear David
> >
> > > -----Original Message-----
> > > From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
> > > Sent: Tuesday, February 10, 2015 5:46 PM
> > > To: Wang, Xiaoming; Konrad Rzeszutek Wilk
> > > Cc: linux-mips@xxxxxxxxxxxxxx; pebolle@xxxxxxxxxx; Zhang, Dongxing;
> > > lauraa@xxxxxxxxxxxxxx; d.kasatkin@xxxxxxxxxxx;
> > > heiko.carstens@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; ralf@linux-
> > > mips.org; chris@xxxxxxxxxxxxxxxxxx; takahiro.akashi@xxxxxxxxxx;
> > > david.vrabel@xxxxxxxxxx; linux@xxxxxxxxxxx; xen-
> > > devel@xxxxxxxxxxxxxxxxxxxx; boris.ostrovsky@xxxxxxxxxx; Liu,
> > > Chuansheng; akpm@xxxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to
> > > io_tlb_segsize configurable as flexible requirement about SW-IOMMU.
> > >
> > > On 06/02/15 00:10, Wang, Xiaoming wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> > > >> Sent: Friday, February 6, 2015 3:33 AM
> > > >> To: Wang, Xiaoming
> > > >> Cc: ralf@xxxxxxxxxxxxxx; boris.ostrovsky@xxxxxxxxxx;
> > > >> david.vrabel@xxxxxxxxxx; linux-mips@xxxxxxxxxxxxxx; linux-
> > > >> kernel@xxxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> > > >> akpm@linux- foundation.org; linux@xxxxxxxxxxx;
> > > >> lauraa@xxxxxxxxxxxxxx; heiko.carstens@xxxxxxxxxx;
> > > >> d.kasatkin@xxxxxxxxxxx; takahiro.akashi@xxxxxxxxxx;
> > > >> chris@xxxxxxxxxxxxxxxxxx; pebolle@xxxxxxxxxx; Liu, Chuansheng;
> > > >> Zhang, Dongxing
> > > >> Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize
> > > >> configurable as flexible requirement about SW-IOMMU.
> > > >>
> > > >> On Fri, Feb 06, 2015 at 07:01:14AM +0800, xiaomin1 wrote:
> > > >>> The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
> > > >>> While in different platform and different requirements this
> > > >>> seems
> > > improper.
> > > >>> So modify the IO_TLB_SEGSIZE to io_tlb_segsize as configurable
> > > >>> is make
> > > >> sense.
> > > >>
> > > >> More details please. What is the issue you are hitting?
> > > >>
> > > > Example:
> > > > If 1M bytes are requied. There has an error like.
> > >
> > > Instead of allowing the bouncing of such large buffers, could the
> > > gadget driver be modified to submit the buffers to the hardware in
> smaller chunks?
> > >
> > > David
> >
> > Our target is try to make IO_TLB_SEGSIZE configurable.
> > Neither 256 bytes  or 1M bytes seems suitable value, I think.
> > It's better to use the tactics something like kmem_cache_create  in
> > kmalloc function.
> > But SW-IOMMU seems more lighter.
> > So we choose variable rather than function.
> 
> Would it be possible to understand why the gadget needs such large buffer?
> That is irrespective of the patchset you are proposing.
> 
> In regards to the pathchset - I don't see anything fundamentally wrong with
> the patch. What I am afraid is that this fixes the symptoms instead of the
> underlaying problem. The problem I think is that with this large 1MB requests
> you risk of using the SWIOTLB bounce buffer which can result in poor
> performance.
> 
> So eventually somebody will have to figure out why the performance is poor
> and have a hard time figuring what is wrong - as the symptoms have been
> removed.
> 
> Hence looking at potentially using an scatter gather mechanism and chop up
> the requests in smaller sizes might be an better option. But I don't know?
> Perhaps you are more familiar with the gadget and could tell me why it needs
> an 1MB size request?
> 
> 
The 1M size is requested when doing flash fastboot in 
system/core/fastbootd/commands/flash.c  defined by Google.
I listed a partial code from flash.c  here.
#define BUFFER_SIZE 1024 * 1024
int current_size = MIN(size - written, BUFFER_SIZE);
(gpt_mmap(&input, written + skip, current_size, data_fd))
mapping->size = ALIGN(size + location_diff, PAGE_SIZE);

> >
> > Xiaoming.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel