Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1185987 > unrolled thread

Re: [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge  when Linux is not using 4KB page Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-07-16 17:40 +0200
    Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec  to be merge when Linux is not using 4KB page Julien Grall <julien.grall@citrix.com> - 2015-07-16 18:20 +0200
      Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to  be merge when Linux is not using 4KB page Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2015-07-16 20:40 +0200
      Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec  to be merge when Linux is not using 4KB page Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-07-17 15:30 +0200
        Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec  to be merge when Linux is not using 4KB page Julien Grall <julien.grall@citrix.com> - 2015-07-17 16:50 +0200
          Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec  to be merge when Linux is not using 4KB page Julien Grall <julien.grall@citrix.com> - 2015-07-17 16:50 +0200
          Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec  to be merge when Linux is not using 4KB page Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-07-17 16:50 +0200

#1185987 — Re: [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

On Fri, 10 Jul 2015, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
> > When Linux is using 64K page granularity, every page will be slipt in
> > multiple non-contiguous 4K MFN (page granularity of Xen).
> 
> But you don't care about that on the Linux layer I think?
> 
> As in, is there an SWIOTLB that does PFN to MFN and vice-versa
> translation?
> 
> I thought that ARM guests are not exposed to the MFN<->PFN logic
> and trying to figure that out to not screw up the DMA engine
> on a PCIe device slurping up contingous MFNs which don't map
> to contingous PFNs?

Dom0 is mapped 1:1, so pfn == mfn normally, however grant maps
unavoidably screw up the 1:1, so the swiotlb jumps in to save the day
when a foreign granted page is involved in a dma operation.

Regarding xen_biovec_phys_mergeable, we could check that all the pfn ==
mfn and return true in that case.


> > I'm not sure how to handle efficiently the check to know whether we can
> > merge 2 biovec with a such case. So for now, always says that biovec are
> > not mergeable.
> > 
> > Signed-off-by: Julien Grall <julien.grall@citrix.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > ---
> >     Changes in v2:
> >         - Remove the workaround and check if the Linux page granularity
> >         is the same as Xen or not
> > ---
> >  drivers/xen/biomerge.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
> > index 0edb91c..571567c 100644
> > --- a/drivers/xen/biomerge.c
> > +++ b/drivers/xen/biomerge.c
> > @@ -6,10 +6,17 @@
> >  bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
> >  			       const struct bio_vec *vec2)
> >  {
> > +#if XEN_PAGE_SIZE == PAGE_SIZE
> >  	unsigned long mfn1 = pfn_to_mfn(page_to_pfn(vec1->bv_page));
> >  	unsigned long mfn2 = pfn_to_mfn(page_to_pfn(vec2->bv_page));
> >  
> >  	return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) &&
> >  		((mfn1 == mfn2) || ((mfn1+1) == mfn2));
> > +#else
> > +	/* XXX: bio_vec are not mergeable when using different page size in
> > +	 * Xen and Linux
> > +	 */
> > +	return 0;
> > +#endif
> >  }
> >  EXPORT_SYMBOL(xen_biovec_phys_mergeable);
> > -- 
> > 2.1.4
> > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1186048 — Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

Hi Stefano,

On 16/07/2015 16:33, Stefano Stabellini wrote:
> On Fri, 10 Jul 2015, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
>>> When Linux is using 64K page granularity, every page will be slipt in
>>> multiple non-contiguous 4K MFN (page granularity of Xen).
>>
>> But you don't care about that on the Linux layer I think?
>>
>> As in, is there an SWIOTLB that does PFN to MFN and vice-versa
>> translation?
>>
>> I thought that ARM guests are not exposed to the MFN<->PFN logic
>> and trying to figure that out to not screw up the DMA engine
>> on a PCIe device slurping up contingous MFNs which don't map
>> to contingous PFNs?
>
> Dom0 is mapped 1:1, so pfn == mfn normally, however grant maps
> unavoidably screw up the 1:1, so the swiotlb jumps in to save the day
> when a foreign granted page is involved in a dma operation.
>
> Regarding xen_biovec_phys_mergeable, we could check that all the pfn ==
> mfn and return true in that case.

I mentioned it in the commit message. Although, we would have to loop on 
every pfn which is slow on 64KB (16 times for every page). Given the 
biovec is called often, I don't think we can do a such things.

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1186184 — Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

On Thu, Jul 16, 2015 at 05:15:41PM +0100, Julien Grall wrote:
> Hi Stefano,
> 
> On 16/07/2015 16:33, Stefano Stabellini wrote:
> >On Fri, 10 Jul 2015, Konrad Rzeszutek Wilk wrote:
> >>On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
> >>>When Linux is using 64K page granularity, every page will be slipt in
> >>>multiple non-contiguous 4K MFN (page granularity of Xen).
> >>
> >>But you don't care about that on the Linux layer I think?
> >>
> >>As in, is there an SWIOTLB that does PFN to MFN and vice-versa
> >>translation?
> >>
> >>I thought that ARM guests are not exposed to the MFN<->PFN logic
> >>and trying to figure that out to not screw up the DMA engine
> >>on a PCIe device slurping up contingous MFNs which don't map
> >>to contingous PFNs?
> >
> >Dom0 is mapped 1:1, so pfn == mfn normally, however grant maps
> >unavoidably screw up the 1:1, so the swiotlb jumps in to save the day
> >when a foreign granted page is involved in a dma operation.
> >
> >Regarding xen_biovec_phys_mergeable, we could check that all the pfn ==
> >mfn and return true in that case.
> 
> I mentioned it in the commit message. Although, we would have to loop on
> every pfn which is slow on 64KB (16 times for every page). Given the biovec
> is called often, I don't think we can do a such things.

OK - it would be good to have the gist of this email thread in the
commit message. Thanks.
> 
> Regards,
> 
> -- 
> Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1186824 — Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

On Thu, 16 Jul 2015, Julien Grall wrote:
> Hi Stefano,
> 
> On 16/07/2015 16:33, Stefano Stabellini wrote:
> > On Fri, 10 Jul 2015, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
> > > > When Linux is using 64K page granularity, every page will be slipt in
> > > > multiple non-contiguous 4K MFN (page granularity of Xen).
> > > 
> > > But you don't care about that on the Linux layer I think?
> > > 
> > > As in, is there an SWIOTLB that does PFN to MFN and vice-versa
> > > translation?
> > > 
> > > I thought that ARM guests are not exposed to the MFN<->PFN logic
> > > and trying to figure that out to not screw up the DMA engine
> > > on a PCIe device slurping up contingous MFNs which don't map
> > > to contingous PFNs?
> > 
> > Dom0 is mapped 1:1, so pfn == mfn normally, however grant maps
> > unavoidably screw up the 1:1, so the swiotlb jumps in to save the day
> > when a foreign granted page is involved in a dma operation.
> > 
> > Regarding xen_biovec_phys_mergeable, we could check that all the pfn ==
> > mfn and return true in that case.
> 
> I mentioned it in the commit message. Although, we would have to loop on every
> pfn which is slow on 64KB (16 times for every page). Given the biovec is
> called often, I don't think we can do a such things.

We would have to run some benchmarks, but I think it would still be a
win. We should write an ad-hoc __pfn_to_mfn translation function that
operates on a range of pfns and simply checks whether an entry is
present in that range. It should be just as fast as __pfn_to_mfn. I
would definitely recommend it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1186880 — Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

On 17/07/15 14:20, Stefano Stabellini wrote:
> We would have to run some benchmarks, but I think it would still be a
> win. We should write an ad-hoc __pfn_to_mfn translation function that
> operates on a range of pfns and simply checks whether an entry is
> present in that range. It should be just as fast as __pfn_to_mfn. I
> would definitely recommend it.

I'd like to see a basic support of 64KB support on Xen pushed in Linux
upstream before looking to possible improvement in the code. Can we
defer this as the follow-up of this series?

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1186881 — Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

On 17/07/15 15:45, Stefano Stabellini wrote:
> On Fri, 17 Jul 2015, Julien Grall wrote:
>> On 17/07/15 14:20, Stefano Stabellini wrote:
>>> We would have to run some benchmarks, but I think it would still be a
>>> win. We should write an ad-hoc __pfn_to_mfn translation function that
>>> operates on a range of pfns and simply checks whether an entry is
>>> present in that range. It should be just as fast as __pfn_to_mfn. I
>>> would definitely recommend it.
>>
>> I'd like to see a basic support of 64KB support on Xen pushed in Linux
>> upstream before looking to possible improvement in the code. Can we
>> defer this as the follow-up of this series?
> 
> Yes, maybe add a TODO comment in the code. 

Will do.

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1186884 — Re: [Xen-devel] [PATCH v2 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page

On Fri, 17 Jul 2015, Julien Grall wrote:
> On 17/07/15 14:20, Stefano Stabellini wrote:
> > We would have to run some benchmarks, but I think it would still be a
> > win. We should write an ad-hoc __pfn_to_mfn translation function that
> > operates on a range of pfns and simply checks whether an entry is
> > present in that range. It should be just as fast as __pfn_to_mfn. I
> > would definitely recommend it.
> 
> I'd like to see a basic support of 64KB support on Xen pushed in Linux
> upstream before looking to possible improvement in the code. Can we
> defer this as the follow-up of this series?

Yes, maybe add a TODO comment in the code. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web