From: Scott Wood <swood-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Sebastian Andrzej Siewior
<bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation
Date: Sat, 17 Mar 2018 14:49:54 -0500 [thread overview]
Message-ID: <1521316194.3722.74.camel@redhat.com> (raw)
In-Reply-To: <20180316201836.7864-1-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
On Fri, 2018-03-16 at 21:18 +0100, Sebastian Andrzej Siewior wrote:
> The goal here is to make the memory allocation in get_irq_table() not
> with disabled interrupts and having as little raw_spin_lock as
> possible
> while having them if the caller is also holding one (like desc->lock
> during IRQ-affinity changes).
> I reverted one patch one patch in the iommu while rebasing since it
> make job easier.
If the goal is to have "as little raw_spin_lock as possible" -- and
presumably also to avoid unnecessary complexity -- wouldn't it be
better to leave my patch in, and drop patches 4 and 9?
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <swood@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de
Subject: Re: [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation
Date: Sat, 17 Mar 2018 14:49:54 -0500 [thread overview]
Message-ID: <1521316194.3722.74.camel@redhat.com> (raw)
In-Reply-To: <20180316201836.7864-1-bigeasy@linutronix.de>
On Fri, 2018-03-16 at 21:18 +0100, Sebastian Andrzej Siewior wrote:
> The goal here is to make the memory allocation in get_irq_table() not
> with disabled interrupts and having as little raw_spin_lock as
> possible
> while having them if the caller is also holding one (like desc->lock
> during IRQ-affinity changes).
> I reverted one patch one patch in the iommu while rebasing since it
> make job easier.
If the goal is to have "as little raw_spin_lock as possible" -- and
presumably also to avoid unnecessary complexity -- wouldn't it be
better to leave my patch in, and drop patches 4 and 9?
-Scott
next prev parent reply other threads:[~2018-03-17 19:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-16 20:18 [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
[not found] ` <20180316201836.7864-1-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2018-03-16 20:18 ` [PATCH 01/10] iommu/amd: take into account that alloc_dev_data() may return NULL Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 02/10] iommu/amd: turn dev_data_list into a lock less list Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 03/10] iommu/amd: split domain id out of amd_iommu_devtable_lock Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 04/10] iommu/amd: split irq_lookup_table out of the amd_iommu_devtable_lock Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 06/10] iommu/amd: remove the special case from get_irq_table() Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 07/10] iommu/amd: use `table' instead `irt' as variable name in amd_iommu_update_ga() Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 08/10] iommu/amd: factor out setting the remap table for a devid Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 09/10] iommu/amd: drop the lock while allocating new irq remap table Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-16 20:18 ` [PATCH 10/10] iommu/amd: make amd_iommu_devtable_lock a spin_lock Sebastian Andrzej Siewior
2018-03-16 20:18 ` Sebastian Andrzej Siewior
2018-03-17 19:49 ` Scott Wood [this message]
2018-03-17 19:49 ` [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation Scott Wood
[not found] ` <1521316194.3722.74.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-17 21:10 ` Sebastian Andrzej Siewior
2018-03-17 21:10 ` Sebastian Andrzej Siewior
[not found] ` <20180317211013.rlou66s542ad4y2i-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2018-03-17 21:43 ` Scott Wood
2018-03-17 21:43 ` Scott Wood
[not found] ` <1521323019.3722.98.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-19 12:15 ` Sebastian Andrzej Siewior
2018-03-19 12:15 ` Sebastian Andrzej Siewior
2018-03-19 22:49 ` Scott Wood
2018-03-16 20:18 ` [PATCH 05/10] Revert "iommu/amd: Avoid locking get_irq_table() from atomic context" Sebastian Andrzej Siewior
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=1521316194.3722.74.camel@redhat.com \
--to=swood-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@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.