All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ganapatrao Kulkarni <gklkml16@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>,
	Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	tomasz.nowicki@cavium.com, jnair@caviumnetworks.com,
	Robert Richter <Robert.Richter@cavium.com>,
	Vadim.Lomovtsev@cavium.com, Jan.Glauber@cavium.com
Subject: Re: [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA
Date: Tue, 31 Jul 2018 08:10:16 +0530	[thread overview]
Message-ID: <CAKTKpr5YqVc8R7=Sorzx=fCVg0YphZUHFO7n1FAj2K2XMytQ=w@mail.gmail.com> (raw)
In-Reply-To: <CAKTKpr5HWUoJL0TcCMmUadtY_Z4p-RnwH7ZNjSxQppw-_=qdOw@mail.gmail.com>

Hi Robin,


On Mon, Jul 30, 2018 at 12:40 PM, Ganapatrao Kulkarni
<gklkml16@gmail.com> wrote:
> On Fri, Jul 27, 2018 at 9:48 PM, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 27/07/18 13:56, Ganapatrao Kulkarni wrote:
>> [...]
>>>>>
>>>>> did you get any chance to look in to this issue?
>>>>> i am waiting for your suggestion/patch for this issue!
>>>>
>>>>
>>>>
>>>> I got as far as [1], but I wasn't sure how much I liked it, since it
>>>> still
>>>> seems a little invasive for such a specific case (plus I can't remember
>>>> if
>>>> it's actually been debugged or not). I think in the end I started
>>>> wondering
>>>> whether it's even worth bothering with the 32-bit optimisation for PCIe
>>>> devices - 4 extra bytes worth of TLP is surely a lot less significant
>>>> than
>>>> every transaction taking up to 50% more bus cycles was for legacy PCI.
>>>
>>>
>>> how about tracking previous attempt to get 32bit range iova and avoid
>>> further attempts, if it was failed. Later Resume attempts once
>>> replenish happens.
>>> Created patch for the same [2]
>>
>>
>> Ooh, that's a much neater implementation of essentially the same concept -
>> now why couldn't I think of that? :)
>>
>> Looks like it should be possible to make it entirely self-contained too,
>> since alloc_iova() is in a position to both test and update the flag based
>> on the limit_pfn passed in.
>
> is below patch much better?

testing with this diff looks ok, shall i send formal patch with your Acked-by?
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 83fe262..abb15d6 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -56,6 +56,7 @@ init_iova_domain(struct iova_domain *iovad, unsigned
> long granule,
>      iovad->granule = granule;
>      iovad->start_pfn = start_pfn;
>      iovad->dma_32bit_pfn = 1UL << (32 - iova_shift(iovad));
> +    iovad->free_32bit_pfns = true;
>      iovad->flush_cb = NULL;
>      iovad->fq = NULL;
>      iovad->anchor.pfn_lo = iovad->anchor.pfn_hi = IOVA_ANCHOR;
> @@ -139,8 +140,10 @@ __cached_rbnode_delete_update(struct iova_domain
> *iovad, struct iova *free)
>
>      cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
>      if (free->pfn_hi < iovad->dma_32bit_pfn &&
> -        free->pfn_lo >= cached_iova->pfn_lo)
> +        free->pfn_lo >= cached_iova->pfn_lo) {
>          iovad->cached32_node = rb_next(&free->node);
> +        iovad->free_32bit_pfns = true;
> +    }
>
>      cached_iova = rb_entry(iovad->cached_node, struct iova, node);
>      if (free->pfn_lo >= cached_iova->pfn_lo)
> @@ -290,6 +293,10 @@ alloc_iova(struct iova_domain *iovad, unsigned long size,
>      struct iova *new_iova;
>      int ret;
>
> +    if (limit_pfn < iovad->dma_32bit_pfn &&
> +            !iovad->free_32bit_pfns)
> +        return NULL;
> +
>      new_iova = alloc_iova_mem();
>      if (!new_iova)
>          return NULL;
> @@ -299,6 +306,8 @@ alloc_iova(struct iova_domain *iovad, unsigned long size,
>
>      if (ret) {
>          free_iova_mem(new_iova);
> +        if (limit_pfn < iovad->dma_32bit_pfn)
> +            iovad->free_32bit_pfns = false;
>          return NULL;
>      }
>
> diff --git a/include/linux/iova.h b/include/linux/iova.h
> index 928442d..3810ba9 100644
> --- a/include/linux/iova.h
> +++ b/include/linux/iova.h
> @@ -96,6 +96,7 @@ struct iova_domain {
>                             flush-queues */
>      atomic_t fq_timer_on;            /* 1 when timer is active, 0
>                             when not */
> +    bool    free_32bit_pfns;
>  };
>
>  static inline unsigned long iova_size(struct iova *iova)
> --
> 2.9.4
>>
>> Robin.
>>
>>
>>>
>>> [2]
>>> https://github.com/gpkulkarni/linux/commit/e2343a3e1f55cdeb5694103dd354bcb881dc65c3
>>> note, the testing of this patch is in progress.
>>>
>>>>
>>>> Robin.
>>>>
>>>> [1]
>>>>
>>>> http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=a8e0e4af10ebebb3669750e05bf0028e5bd6afe8
>>>
>>>
>>> thanks
>>> Ganapat
>>>
>>
>
> thanks
> Ganapat

thanks
Ganapat

WARNING: multiple messages have this Message-ID (diff)
From: Ganapatrao Kulkarni <gklkml16-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: Vadim.Lomovtsev-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	Jan.Glauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	tomasz.nowicki-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org,
	Ganapatrao Kulkarni
	<ganapatrao.kulkarni-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>,
	Robert Richter
	<Robert.Richter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA
Date: Tue, 31 Jul 2018 08:10:16 +0530	[thread overview]
Message-ID: <CAKTKpr5YqVc8R7=Sorzx=fCVg0YphZUHFO7n1FAj2K2XMytQ=w@mail.gmail.com> (raw)
In-Reply-To: <CAKTKpr5HWUoJL0TcCMmUadtY_Z4p-RnwH7ZNjSxQppw-_=qdOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Robin,


On Mon, Jul 30, 2018 at 12:40 PM, Ganapatrao Kulkarni
<gklkml16-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jul 27, 2018 at 9:48 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 27/07/18 13:56, Ganapatrao Kulkarni wrote:
>> [...]
>>>>>
>>>>> did you get any chance to look in to this issue?
>>>>> i am waiting for your suggestion/patch for this issue!
>>>>
>>>>
>>>>
>>>> I got as far as [1], but I wasn't sure how much I liked it, since it
>>>> still
>>>> seems a little invasive for such a specific case (plus I can't remember
>>>> if
>>>> it's actually been debugged or not). I think in the end I started
>>>> wondering
>>>> whether it's even worth bothering with the 32-bit optimisation for PCIe
>>>> devices - 4 extra bytes worth of TLP is surely a lot less significant
>>>> than
>>>> every transaction taking up to 50% more bus cycles was for legacy PCI.
>>>
>>>
>>> how about tracking previous attempt to get 32bit range iova and avoid
>>> further attempts, if it was failed. Later Resume attempts once
>>> replenish happens.
>>> Created patch for the same [2]
>>
>>
>> Ooh, that's a much neater implementation of essentially the same concept -
>> now why couldn't I think of that? :)
>>
>> Looks like it should be possible to make it entirely self-contained too,
>> since alloc_iova() is in a position to both test and update the flag based
>> on the limit_pfn passed in.
>
> is below patch much better?

testing with this diff looks ok, shall i send formal patch with your Acked-by?
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 83fe262..abb15d6 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -56,6 +56,7 @@ init_iova_domain(struct iova_domain *iovad, unsigned
> long granule,
>      iovad->granule = granule;
>      iovad->start_pfn = start_pfn;
>      iovad->dma_32bit_pfn = 1UL << (32 - iova_shift(iovad));
> +    iovad->free_32bit_pfns = true;
>      iovad->flush_cb = NULL;
>      iovad->fq = NULL;
>      iovad->anchor.pfn_lo = iovad->anchor.pfn_hi = IOVA_ANCHOR;
> @@ -139,8 +140,10 @@ __cached_rbnode_delete_update(struct iova_domain
> *iovad, struct iova *free)
>
>      cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
>      if (free->pfn_hi < iovad->dma_32bit_pfn &&
> -        free->pfn_lo >= cached_iova->pfn_lo)
> +        free->pfn_lo >= cached_iova->pfn_lo) {
>          iovad->cached32_node = rb_next(&free->node);
> +        iovad->free_32bit_pfns = true;
> +    }
>
>      cached_iova = rb_entry(iovad->cached_node, struct iova, node);
>      if (free->pfn_lo >= cached_iova->pfn_lo)
> @@ -290,6 +293,10 @@ alloc_iova(struct iova_domain *iovad, unsigned long size,
>      struct iova *new_iova;
>      int ret;
>
> +    if (limit_pfn < iovad->dma_32bit_pfn &&
> +            !iovad->free_32bit_pfns)
> +        return NULL;
> +
>      new_iova = alloc_iova_mem();
>      if (!new_iova)
>          return NULL;
> @@ -299,6 +306,8 @@ alloc_iova(struct iova_domain *iovad, unsigned long size,
>
>      if (ret) {
>          free_iova_mem(new_iova);
> +        if (limit_pfn < iovad->dma_32bit_pfn)
> +            iovad->free_32bit_pfns = false;
>          return NULL;
>      }
>
> diff --git a/include/linux/iova.h b/include/linux/iova.h
> index 928442d..3810ba9 100644
> --- a/include/linux/iova.h
> +++ b/include/linux/iova.h
> @@ -96,6 +96,7 @@ struct iova_domain {
>                             flush-queues */
>      atomic_t fq_timer_on;            /* 1 when timer is active, 0
>                             when not */
> +    bool    free_32bit_pfns;
>  };
>
>  static inline unsigned long iova_size(struct iova *iova)
> --
> 2.9.4
>>
>> Robin.
>>
>>
>>>
>>> [2]
>>> https://github.com/gpkulkarni/linux/commit/e2343a3e1f55cdeb5694103dd354bcb881dc65c3
>>> note, the testing of this patch is in progress.
>>>
>>>>
>>>> Robin.
>>>>
>>>> [1]
>>>>
>>>> http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=a8e0e4af10ebebb3669750e05bf0028e5bd6afe8
>>>
>>>
>>> thanks
>>> Ganapat
>>>
>>
>
> thanks
> Ganapat

thanks
Ganapat

  reply	other threads:[~2018-07-31  2:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 17:12 [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA Ganapatrao Kulkarni
2018-04-19 17:12 ` Ganapatrao Kulkarni
2018-04-23 16:37 ` Robin Murphy
2018-04-23 16:37   ` Robin Murphy
2018-04-23 17:41   ` Ganapatrao Kulkarni
2018-04-23 17:41     ` Ganapatrao Kulkarni
2018-04-26  9:45     ` Ganapatrao Kulkarni
2018-04-26  9:45       ` Ganapatrao Kulkarni
2018-05-21  1:15       ` Ganapatrao Kulkarni
2018-05-21  1:15         ` Ganapatrao Kulkarni
2018-06-04  4:06         ` Ganapatrao Kulkarni
2018-07-12  7:45           ` Ganapatrao Kulkarni
2018-07-25 14:20             ` Robin Murphy
2018-07-27 12:56               ` Ganapatrao Kulkarni
2018-07-27 16:18                 ` Robin Murphy
2018-07-30  7:10                   ` Ganapatrao Kulkarni
2018-07-31  2:40                     ` Ganapatrao Kulkarni [this message]
2018-07-31  2:40                       ` Ganapatrao Kulkarni

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='CAKTKpr5YqVc8R7=Sorzx=fCVg0YphZUHFO7n1FAj2K2XMytQ=w@mail.gmail.com' \
    --to=gklkml16@gmail.com \
    --cc=Jan.Glauber@cavium.com \
    --cc=Robert.Richter@cavium.com \
    --cc=Vadim.Lomovtsev@cavium.com \
    --cc=ganapatrao.kulkarni@cavium.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jnair@caviumnetworks.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tomasz.nowicki@cavium.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.