From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
<Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org"
<prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Robin Murphy <Robin.Murphy-5wv7dgnIgG8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 0/4] Generic IOMMU page table framework
Date: Tue, 2 Dec 2014 13:53:56 +0000 [thread overview]
Message-ID: <20141202135356.GF9917@arm.com> (raw)
In-Reply-To: <1669896.md3tuDH5WL@avalon>
On Tue, Dec 02, 2014 at 01:47:41PM +0000, Laurent Pinchart wrote:
> On Monday 01 December 2014 12:05:34 Will Deacon wrote:
> > On Sun, Nov 30, 2014 at 10:03:08PM +0000, Laurent Pinchart wrote:
> > > On Thursday 27 November 2014 11:51:14 Will Deacon wrote:
> > > > The LPAE code implements support for 4k/2M/1G, 16k/32M and 64k/512M
> > > > mappings, but I decided not to implement the contiguous bit in the
> > > > interest of trying to keep the code semi-readable. This could always be
> > > > added later, if needed.
> > >
> > > Do you have any idea how much the contiguous bit can improve performances
> > > in real use cases ?
> >
> > It depends on the TLB, really. Given that the contiguous sized map directly
> > onto block sizes using different granules, I didn't see that the complexity
> > was worth it.
> >
> > For example:
> >
> > 4k granule : 16 contiguous entries => {64k, 32M, 16G}
> > 16k granule : 128 contiguous lvl3 entries => 2M
> > 32 contiguous lvl2 entries => 1G
> > 64k granule : 32 contiguous entries => {2M, 16G}
> >
> > If we use block mappings, then we get:
> >
> > 4k granule : 2M @ lvl2, 1G @ lvl1
> > 16k granule : 32M @ lvl2
> > 64k granule : 512M @ lvl2
> >
> > so really, we only miss the ability to create 16G mappings.
>
> In the general case maybe, but as far as I know my IOMMU only supports 4kB
> granule. Without support for the contiguous bit I loose the ability to create
> 64kB mappings, which I believe (but haven't test yet) will have a noticeable
> impact.
It would be good if you could confirm that. I'd have thought that you'd end
up using 2MB mappings most of the time for DMA buffers.
> > I doubt that hardware even implements that size in the TLB (the contiguous
> > bit is only a hint).
> >
> > On top of that, the contiguous bit leads to additional expense on unmap,
> > since you have extra TLB invalidation splitting the thing into non-
> > contiguous pages before you can do anything.
>
> That will only be required when doing partial unmaps, which shouldn't be that
> frequent. When unmapping a 64kB block there's no need to split the mapping
> beforehand.
Sure. I'm not against having support for the contiguous bit, I just don't
plan to implement it myself :)
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] Generic IOMMU page table framework
Date: Tue, 2 Dec 2014 13:53:56 +0000 [thread overview]
Message-ID: <20141202135356.GF9917@arm.com> (raw)
In-Reply-To: <1669896.md3tuDH5WL@avalon>
On Tue, Dec 02, 2014 at 01:47:41PM +0000, Laurent Pinchart wrote:
> On Monday 01 December 2014 12:05:34 Will Deacon wrote:
> > On Sun, Nov 30, 2014 at 10:03:08PM +0000, Laurent Pinchart wrote:
> > > On Thursday 27 November 2014 11:51:14 Will Deacon wrote:
> > > > The LPAE code implements support for 4k/2M/1G, 16k/32M and 64k/512M
> > > > mappings, but I decided not to implement the contiguous bit in the
> > > > interest of trying to keep the code semi-readable. This could always be
> > > > added later, if needed.
> > >
> > > Do you have any idea how much the contiguous bit can improve performances
> > > in real use cases ?
> >
> > It depends on the TLB, really. Given that the contiguous sized map directly
> > onto block sizes using different granules, I didn't see that the complexity
> > was worth it.
> >
> > For example:
> >
> > 4k granule : 16 contiguous entries => {64k, 32M, 16G}
> > 16k granule : 128 contiguous lvl3 entries => 2M
> > 32 contiguous lvl2 entries => 1G
> > 64k granule : 32 contiguous entries => {2M, 16G}
> >
> > If we use block mappings, then we get:
> >
> > 4k granule : 2M @ lvl2, 1G @ lvl1
> > 16k granule : 32M @ lvl2
> > 64k granule : 512M @ lvl2
> >
> > so really, we only miss the ability to create 16G mappings.
>
> In the general case maybe, but as far as I know my IOMMU only supports 4kB
> granule. Without support for the contiguous bit I loose the ability to create
> 64kB mappings, which I believe (but haven't test yet) will have a noticeable
> impact.
It would be good if you could confirm that. I'd have thought that you'd end
up using 2MB mappings most of the time for DMA buffers.
> > I doubt that hardware even implements that size in the TLB (the contiguous
> > bit is only a hint).
> >
> > On top of that, the contiguous bit leads to additional expense on unmap,
> > since you have extra TLB invalidation splitting the thing into non-
> > contiguous pages before you can do anything.
>
> That will only be required when doing partial unmaps, which shouldn't be that
> frequent. When unmapping a 64kB block there's no need to split the mapping
> beforehand.
Sure. I'm not against having support for the contiguous bit, I just don't
plan to implement it myself :)
Will
next prev parent reply other threads:[~2014-12-02 13:53 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 11:51 [PATCH 0/4] Generic IOMMU page table framework Will Deacon
2014-11-27 11:51 ` Will Deacon
[not found] ` <1417089078-22900-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-11-27 11:51 ` [PATCH 1/4] iommu: introduce generic page table allocation framework Will Deacon
2014-11-27 11:51 ` Will Deacon
[not found] ` <1417089078-22900-2-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-11-30 22:00 ` Laurent Pinchart
2014-11-30 22:00 ` Laurent Pinchart
2014-12-01 12:13 ` Will Deacon
2014-12-01 12:13 ` Will Deacon
[not found] ` <20141201121338.GD18466-5wv7dgnIgG8@public.gmane.org>
2014-12-01 13:33 ` Laurent Pinchart
2014-12-01 13:33 ` Laurent Pinchart
2014-12-01 13:53 ` Will Deacon
2014-12-01 13:53 ` Will Deacon
2014-12-14 23:46 ` Laurent Pinchart
2014-12-14 23:46 ` Laurent Pinchart
2014-12-15 9:45 ` Will Deacon
2014-12-15 9:45 ` Will Deacon
2014-11-27 11:51 ` [PATCH 2/4] iommu: add ARM LPAE page table allocator Will Deacon
2014-11-27 11:51 ` Will Deacon
[not found] ` <1417089078-22900-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-11-30 23:29 ` Laurent Pinchart
2014-11-30 23:29 ` Laurent Pinchart
2014-12-01 17:23 ` Will Deacon
2014-12-01 17:23 ` Will Deacon
[not found] ` <20141201172315.GI18466-5wv7dgnIgG8@public.gmane.org>
2014-12-01 20:21 ` Laurent Pinchart
2014-12-01 20:21 ` Laurent Pinchart
2014-12-02 9:41 ` Will Deacon
2014-12-02 9:41 ` Will Deacon
[not found] ` <20141202094156.GB9917-5wv7dgnIgG8@public.gmane.org>
2014-12-02 11:47 ` Laurent Pinchart
2014-12-02 11:47 ` Laurent Pinchart
2014-12-05 18:48 ` Will Deacon
2014-12-05 18:48 ` Will Deacon
2014-12-02 22:41 ` Mitchel Humpherys
2014-12-02 22:41 ` Mitchel Humpherys
[not found] ` <vnkw8uipznbj.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2014-12-03 11:11 ` Will Deacon
2014-12-03 11:11 ` Will Deacon
2014-12-05 10:55 ` Varun Sethi
2014-12-05 10:55 ` Varun Sethi
[not found] ` <BN3PR0301MB12198CE5D736CDC6A221EDC2EA790-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2014-12-05 18:48 ` Will Deacon
2014-12-05 18:48 ` Will Deacon
[not found] ` <20141205184802.GH1203-5wv7dgnIgG8@public.gmane.org>
2014-12-14 17:45 ` Varun Sethi
2014-12-14 17:45 ` Varun Sethi
[not found] ` <BN3PR0301MB1219D3161E4E9DB314FDD8FAEA6E0-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2014-12-15 13:30 ` Will Deacon
2014-12-15 13:30 ` Will Deacon
[not found] ` <20141215133020.GJ20738-5wv7dgnIgG8@public.gmane.org>
2014-12-15 15:43 ` Will Deacon
2014-12-15 15:43 ` Will Deacon
2014-12-15 16:35 ` Varun Sethi
2014-12-15 16:35 ` Varun Sethi
[not found] ` <BN3PR0301MB12194A8F5CFF870B7A124623EA6F0-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2014-12-15 17:25 ` Will Deacon
2014-12-15 17:25 ` Will Deacon
2014-12-15 16:43 ` Varun Sethi
2014-12-15 16:43 ` Varun Sethi
[not found] ` <BN3PR0301MB12199C5CAD33E745CC7E51F4EA6F0-CEkquS/Gb81uuip9JPHoc5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2014-12-15 17:20 ` Will Deacon
2014-12-15 17:20 ` Will Deacon
2014-11-27 11:51 ` [PATCH 3/4] iommu: add self-consistency tests to ARM LPAE IO " Will Deacon
2014-11-27 11:51 ` Will Deacon
2014-11-27 11:51 ` [PATCH 4/4] iommu/arm-smmu: make use of generic LPAE allocator Will Deacon
2014-11-27 11:51 ` Will Deacon
2014-11-30 22:03 ` [PATCH 0/4] Generic IOMMU page table framework Laurent Pinchart
2014-11-30 22:03 ` Laurent Pinchart
2014-12-01 12:05 ` Will Deacon
2014-12-01 12:05 ` Will Deacon
[not found] ` <20141201120534.GC18466-5wv7dgnIgG8@public.gmane.org>
2014-12-02 13:47 ` Laurent Pinchart
2014-12-02 13:47 ` Laurent Pinchart
2014-12-02 13:53 ` Will Deacon [this message]
2014-12-02 13:53 ` Will Deacon
[not found] ` <20141202135356.GF9917-5wv7dgnIgG8@public.gmane.org>
2014-12-02 22:29 ` Laurent Pinchart
2014-12-02 22:29 ` Laurent Pinchart
2014-12-14 23:49 ` Laurent Pinchart
2014-12-14 23:49 ` Laurent Pinchart
2014-12-15 16:10 ` Will Deacon
2014-12-15 16:10 ` Will Deacon
[not found] ` <20141215161052.GM20738-5wv7dgnIgG8@public.gmane.org>
2014-12-15 17:33 ` Laurent Pinchart
2014-12-15 17:33 ` Laurent Pinchart
2014-12-15 17:39 ` Will Deacon
2014-12-15 17:39 ` Will Deacon
[not found] ` <20141215173911.GT20738-5wv7dgnIgG8@public.gmane.org>
2014-12-15 17:46 ` Laurent Pinchart
2014-12-15 17:46 ` Laurent Pinchart
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=20141202135356.GF9917@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=Robin.Murphy-5wv7dgnIgG8@public.gmane.org \
--cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.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.