All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: aik@au1.ibm.com, aik@ozlabs.ru, anton@au1.ibm.com,
	paulus@samba.org, sparclinux@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, David Miller <davem@davemloft.net>
Subject: Re: Generic IOMMU pooled allocator
Date: Mon, 23 Mar 2015 19:19:43 -0400	[thread overview]
Message-ID: <20150323231943.GC21966@oracle.com> (raw)
In-Reply-To: <1427150202.4770.248.camel@kernel.crashing.org>

On (03/24/15 09:36), Benjamin Herrenschmidt wrote:
> 
>  - One pool only
> 
>  - Whenever the allocation is before the previous hint, do a flush, that
> should only happen if a wrap around occurred or in some cases if the
> device DMA mask forced it. I think we always update the hint whenever we
> successfully allocate from the small pools.

right, I believe this is close to what I discussed in the previous
thread, and approx what I have in patchv5, except that the flush 
indirection can be passed as a function pointer, or via the table_ops.

> 
>  - Deal with the largealloc case. That's the contentious issue, see
> below.
  :
> The largealloc issue is a different can of worms. We can try adding an
> option to disable the largealloc business completely (instead of hard
> wiring the "15", make that a variable and define that 0 means no
> largealloc pool).

What I've tried to do is to have a bool large_pool arg passed
to iommu_tbl_pool_init. In my observation (instrumented for scsi, ixgbe), 
we never allocate more than 4 pages at a time, so I pass in 
large_pool == false for all the sparc platforms. 

> Or we can decide that large allocs are rare (typically
> pci_alloc_consistent, ie, driver init time), and thus always flush on
> them (or rather on free of a large chunk). David, what's your take
> there ? I have a feeling that should work fine without a noticeable
> performance issue...
> 
> I would also keep a "dirty" flag set on any free and cleared on any
> flush to avoid more spurrious flushes, but here too the benefit might be
> in the noise.

WARNING: multiple messages have this Message-ID (diff)
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: aik@au1.ibm.com, aik@ozlabs.ru, anton@au1.ibm.com,
	paulus@samba.org, sparclinux@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, David Miller <davem@davemloft.net>
Subject: Re: Generic IOMMU pooled allocator
Date: Mon, 23 Mar 2015 23:19:43 +0000	[thread overview]
Message-ID: <20150323231943.GC21966@oracle.com> (raw)
In-Reply-To: <1427150202.4770.248.camel@kernel.crashing.org>

On (03/24/15 09:36), Benjamin Herrenschmidt wrote:
> 
>  - One pool only
> 
>  - Whenever the allocation is before the previous hint, do a flush, that
> should only happen if a wrap around occurred or in some cases if the
> device DMA mask forced it. I think we always update the hint whenever we
> successfully allocate from the small pools.

right, I believe this is close to what I discussed in the previous
thread, and approx what I have in patchv5, except that the flush 
indirection can be passed as a function pointer, or via the table_ops.

> 
>  - Deal with the largealloc case. That's the contentious issue, see
> below.
  :
> The largealloc issue is a different can of worms. We can try adding an
> option to disable the largealloc business completely (instead of hard
> wiring the "15", make that a variable and define that 0 means no
> largealloc pool).

What I've tried to do is to have a bool large_pool arg passed
to iommu_tbl_pool_init. In my observation (instrumented for scsi, ixgbe), 
we never allocate more than 4 pages at a time, so I pass in 
large_pool = false for all the sparc platforms. 

> Or we can decide that large allocs are rare (typically
> pci_alloc_consistent, ie, driver init time), and thus always flush on
> them (or rather on free of a large chunk). David, what's your take
> there ? I have a feeling that should work fine without a noticeable
> performance issue...
> 
> I would also keep a "dirty" flag set on any free and cleared on any
> flush to avoid more spurrious flushes, but here too the benefit might be
> in the noise.

  reply	other threads:[~2015-03-23 23:19 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19  2:25 Generic IOMMU pooled allocator David Miller
2015-03-19  2:25 ` David Miller
2015-03-19  2:46 ` Benjamin Herrenschmidt
2015-03-19  2:46   ` Benjamin Herrenschmidt
2015-03-19  2:50   ` David Miller
2015-03-19  2:50     ` David Miller
2015-03-19  3:01 ` Benjamin Herrenschmidt
2015-03-19  3:01   ` Benjamin Herrenschmidt
2015-03-19  5:27   ` Alexey Kardashevskiy
2015-03-19  5:27     ` Alexey Kardashevskiy
2015-03-19 13:34     ` Sowmini Varadhan
2015-03-19 13:34       ` Sowmini Varadhan
2015-03-22 19:27     ` Sowmini Varadhan
2015-03-22 19:27       ` Sowmini Varadhan
2015-03-23 16:29       ` David Miller
2015-03-23 16:29         ` David Miller
2015-03-23 16:54         ` Sowmini Varadhan
2015-03-23 16:54           ` Sowmini Varadhan
2015-03-23 19:05           ` David Miller
2015-03-23 19:05             ` David Miller
2015-03-23 19:09             ` Sowmini Varadhan
2015-03-23 19:09               ` Sowmini Varadhan
2015-03-23 22:21             ` Benjamin Herrenschmidt
2015-03-23 22:21               ` Benjamin Herrenschmidt
2015-03-23 23:08               ` Sowmini Varadhan
2015-03-23 23:08                 ` Sowmini Varadhan
2015-03-23 23:29                 ` chase rayfield
2015-03-24  0:47                 ` Benjamin Herrenschmidt
2015-03-24  0:47                   ` Benjamin Herrenschmidt
2015-03-24  1:11                   ` Sowmini Varadhan
2015-03-24  1:11                     ` Sowmini Varadhan
2015-03-24  1:44               ` David Miller
2015-03-24  1:44                 ` David Miller
2015-03-24  1:57                 ` Sowmini Varadhan
2015-03-24  1:57                   ` Sowmini Varadhan
2015-03-24  2:08                 ` Benjamin Herrenschmidt
2015-03-24  2:08                   ` Benjamin Herrenschmidt
2015-03-24  2:15                   ` David Miller
2015-03-24  2:15                     ` David Miller
2015-03-26  0:43                     ` cascardo
2015-03-26  0:43                       ` cascardo
2015-03-26  0:49                       ` Benjamin Herrenschmidt
2015-03-26  0:49                         ` Benjamin Herrenschmidt
2015-03-26 10:56                       ` Sowmini Varadhan
2015-03-26 10:56                         ` Sowmini Varadhan
2015-03-26 22:51                       ` David Miller
2015-03-26 23:00                         ` David Miller
2015-03-26 23:51                         ` Benjamin Herrenschmidt
2015-03-26 23:51                           ` Benjamin Herrenschmidt
2015-03-23 22:36             ` Benjamin Herrenschmidt
2015-03-23 22:36               ` Benjamin Herrenschmidt
2015-03-23 23:19               ` Sowmini Varadhan [this message]
2015-03-23 23:19                 ` Sowmini Varadhan
2015-03-24  0:48                 ` Benjamin Herrenschmidt
2015-03-24  0:48                   ` Benjamin Herrenschmidt
2015-03-23 22:25           ` Benjamin Herrenschmidt
2015-03-23 22:25             ` Benjamin Herrenschmidt
2015-03-22 19:36 ` Arnd Bergmann
2015-03-22 19:36   ` Arnd Bergmann
2015-03-22 22:02   ` Benjamin Herrenschmidt
2015-03-22 22:02     ` Benjamin Herrenschmidt
2015-03-22 22:07     ` Sowmini Varadhan
2015-03-22 22:07       ` Sowmini Varadhan
2015-03-22 22:22       ` Benjamin Herrenschmidt
2015-03-22 22:22         ` Benjamin Herrenschmidt
2015-03-23  6:04         ` Arnd Bergmann
2015-03-23  6:04           ` Arnd Bergmann
2015-03-23 11:04           ` Benjamin Herrenschmidt
2015-03-23 11:04             ` Benjamin Herrenschmidt
2015-03-23 18:45             ` Arnd Bergmann
2015-03-23 18:45               ` Arnd Bergmann

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=20150323231943.GC21966@oracle.com \
    --to=sowmini.varadhan@oracle.com \
    --cc=aik@au1.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=anton@au1.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=sparclinux@vger.kernel.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.