From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: "Maciej Grochowski" <Maciej.Grochowski@sony.com>,
"Geramy Loveless" <gloveless@jqluv.com>,
"Eric Auger" <eauger@redhat.com>,
"Alexey Fomenko" <alexey.fomenko@intel.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Mesih Kilinc" <Mesih.Kilinc@sony.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 00/14] PCI: Resource placement algorithm fixes
Date: Mon, 9 Nov 2026 17:27:00 -0600 [thread overview]
Message-ID: <20261109232700.GA345907@bhelgaas> (raw)
In-Reply-To: <20261106134341.39493-1-ilpo.jarvinen@linux.intel.com>
On Fri, Nov 06, 2026 at 03:43:21PM +0200, Ilpo Järvinen wrote:
> V4 got quite many comments from sashiko, some of them were a bit
> sketchy (bogus scenarios such as IOV BARs on a bridge) but there was
> still good feedback hidden under the clearly flawed facade.
>
> There have been major changes so any retesting is appreciated (the
> 4 candidates patch is largely the same so I kept the Tested-by tags but
> everything around has been changing so even that is on the borderline
> when it comes to the validity of the existing tags).
>
> I ended up dropping the nested window fix which I had anyway realized
> would not be necessary with the current resource code. I had earlier
> planned to change the resource side code to only try start addresses
> that qualify to size+align requirements and had thus kept the nested
> win fix. But it just makes PCI side more complicated requiring extra
> tweaks and checks. With that patch dropped, pci_align_resource() can
> alone decide the placement making the code much simpler.
>
> Second major change is rewriting the gap calculation, which required
> including pbus_size_mem() refactoring that I was planning on doing
> anyway.
>
> As with v4, the quirk is not included and one approach should still
> be selected to solve the Genoa/Zen4 iomem blackhole but that's not
> likely the one I proposed within my series so I left it out.
>
> This series also does not attempt to address cases where user alignment
> override does not propagate to window size calculations and thus not
> into the align given to resource placement code (reported by sashiko).
> These are pre-existing issues and while they should be fixed
> eventually, I've no plans on increasing the scope and complexity of
> this series that is focused on solving real regressions caused by the
> commit 9036bd0efcb6 ("PCI: Align head space better").
>
> For those who haven't read the previous version intros (no changes
> from v4 in this):
>
> This series generalizes the resource placement algorithm. The commit
> 9036bd0efcb6 ("PCI: Align head space better") special cased one
> composite resource remainder case to fix a regression (in a long chain
> of regression fixes). Unfortunately, it introduced another regression
> (or a few, to be more accurate).
>
> Instead of building more special tricks, generalize the PCI resource
> placement algorithm so it returns placement that gives better chances
> for the greedy assignment algorithm to find suitable space for
> subsequent assignments.
>
> In short words, the new approach tries to find a placement for the
> current resource that blocks as little of the free space range as
> possible, considering both alignment and continuous free span of the
> remaining free space.
>
> In addition, the series corrects composite resource sizing to account
> for gaps that have to be added due to alignment constraints and
> remainder space not fully connecting (filling space all the way to
> the bridge window align).
>
> More detailed explanations in the patches themselves.
>
> Unfortunately, this also causes yet another regression due to shuffling
> resources around. I've left my quirk out of this version as it seems
> the least likely approach to be used to resolve the issue. Some approach
> should still be applied but that decision seems largely independent of
> this series. The main part of the quirk discussion is here:
>
> https://lore.kernel.org/linux-pci/20261013130948.6231-9-ilpo.jarvinen@linux.intel.com/
>
> I find it likely that after this series the resources are packed tight
> enough to solve also
> https://bugzilla.kernel.org/show_bug.cgi?id=220016
> from more than a year back but that remains to be seen (if we can still
> get the reporter to test it).
>
>
> I planning on making another series to properly honor
> pci=resource_alignment and improve locking as I realized the current
> approach allows parameter change to race with the fitting and
> assignment algorithm.
>
> v5:
> - Reordered series, "simple" patches first
> - Added patch to skip resource with IORESOURCE_DISABLED
> - Added patches to fix __ffs*() (__ffs64 & zero handling)
> - Fix 2 more 1UL -> 1ULL, renamed roundup/down funcs to _u64
> - Rework considering user/arch min align, always take it into
> account during placement if present (sashiko)
> - Rename pci_init_pci_resreq_data() -> pci_init_resreq_data() and make
> it non-inline func
> - Drop nested window fix (unnecessary and w/o complexity is less)
> - Rename .user_align -> .min_align
> - Use struct to store candidate selection parameters
> - Rework candidate selection precedence
> - Calculate odd-multiple starting "2 blocks resource" using both blocks
> - Add a tie breaker to candidate selection using alignment of the left
> edge
> - Do not use candidate logic if there's no full block or
> rr->min_align > align (the latter is due to pre-existing problems
> elsewhere).
> - If no candidate is possible, return right edge of the empty res
> (not strictly necessary because one of the candidates is at res->start
> and the caller should use large enough align if user align is present
> but it doesn't hurt either)
> - Refactor pbus_size_mem() to support the new gap calculation
> - Reworked gap calculation entirely
> - Added debug print to sizing function
> - Fix many grammar errors / typos / consistency improvements
>
> v4:
> - Drop my own quirk patch (one approach should still be picked!)
> - Use 1ULL to not lose bits in 32-bit case (sashiko)
> - Copy avail flags from full_avail.flags (sashiko)
> - Always return "resize" from pci_specified_resource_alignment() (sashiko)
>
> v3:
> - Add roundup/down_pow_of_two64() (new patch) to avoid problems if
> resource_size_t is 64-bit and unsigned long is 32-bit + use __ffs64()
> (multiple potential issues mentioned by sashiko)
> - Do not print res->parent in parisc debug code as the resource is never
> in the resource tree (found by sashiko).
> - Do not override user-alignment with the remainder moves (sashiko)
> - Consider optional sizes properly when sizing bridge window gaps (sashiko)
> - Move genoa quirk under arch/x86/
> - Rename quirk's static resource variable
>
> v2:
> - Add patch to cleanup parisc debug print (do dyndbg conversion)
> - Add patch to prevent remainder tricks when alignment override is used
> (found by sashiko)
> - Do not use PCIBIOS_MIN_IO/MEM but 1U as min align. The former seem
> address space lower bounds even if parisc arch code misleadingly
> uses them for ALIGN() call.
> - Fix res->end + 1 overflow case (found by sashiko)
> - Tweak debug print formatting
> - Reworked the iomem black hole quirk (now based on the bridge)
>
>
> Ilpo Järvinen (14):
> resource: Mark free space assigned
> parisc/PCI: Clean up resource debug print & use dynamic debug
> PCI: Don't size or assign disabled BARs
> PCI: Use __ffs64() for resource_size_t typed align
> PCI: Prevent zero align from reaching __ffs64()
> linux/log2.h: Add 64-bit roundup/down_pow_of_two_u64() variants
> PCI: Derive aligns[] array size in a define
> PCI: Honor alignment overrides
> PCI: Place resources to either edge of the window
> PCI: Separate align/raw size calculation from pbus_size_mem()
> PCI: Calculate bridge window with optional sizes from scratch
> PCI: Move size/align calculation fully into __pbus_size_mem()
> PCI: Fix composite resource sizing
> PCI: Add debug printing to window sizing
It looks like the early ones are straightforward and good-to-go. How
many could we just apply in order to get them out of the way?
I'm guessing at least the first six (up to and including "PCI: Derive
aligns[] array size in a define")?
You mentioned "this also causes yet another regression" so I assume
there's something we're not quite ready to merge yet? I'd like to get
the rest in linux-next as soon as we can.
> arch/alpha/kernel/pci.c | 3 +-
> arch/arm/kernel/bios32.c | 5 +-
> arch/m68k/kernel/pcibios.c | 4 +-
> arch/mips/pci/pci-generic.c | 5 +-
> arch/mips/pci/pci-legacy.c | 5 +-
> arch/parisc/kernel/pci.c | 20 +--
> arch/powerpc/kernel/pci-common.c | 5 +-
> arch/sh/drivers/pci/pci.c | 5 +-
> arch/x86/pci/i386.c | 5 +-
> arch/xtensa/kernel/pci.c | 5 +-
> drivers/char/agp/intel-gtt.c | 5 +-
> drivers/gpu/drm/i915/i915_gmch.c | 5 +-
> drivers/pci/pci.c | 4 +-
> drivers/pci/pci.h | 6 +
> drivers/pci/setup-bus.c | 263 ++++++++++++++++++++-----------
> drivers/pci/setup-res.c | 246 ++++++++++++++++++++++++++---
> include/linux/log2.h | 52 ++++++
> include/linux/pci.h | 15 +-
> kernel/resource.c | 3 +-
> 19 files changed, 510 insertions(+), 151 deletions(-)
>
>
> base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
> --
> 2.47.3
>
prev parent reply other threads:[~2026-11-09 23:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 13:43 Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 01/14] resource: Mark free space assigned Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 02/14] parisc/PCI: Clean up resource debug print & use dynamic debug Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 03/14] PCI: Don't size or assign disabled BARs Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 04/14] PCI: Use __ffs64() for resource_size_t typed align Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 05/14] PCI: Prevent zero align from reaching __ffs64() Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 06/14] linux/log2.h: Add 64-bit roundup/down_pow_of_two_u64() variants Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 07/14] PCI: Derive aligns[] array size in a define Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 08/14] PCI: Honor alignment overrides Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 09/14] PCI: Place resources to either edge of the window Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 10/14] PCI: Separate align/raw size calculation from pbus_size_mem() Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 11/14] PCI: Calculate bridge window with optional sizes from scratch Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 12/14] PCI: Move size/align calculation fully into __pbus_size_mem() Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 13/14] PCI: Fix composite resource sizing Ilpo Järvinen
2026-11-06 13:43 ` [PATCH v5 14/14] PCI: Add debug printing to window sizing Ilpo Järvinen
2026-11-06 15:26 ` [PATCH v5 00/14] PCI: Resource placement algorithm fixes Nikolas Joshua Britton
2026-11-06 16:43 ` Ilpo Järvinen
2026-11-08 1:51 ` Doug Calobrisi
2026-11-09 23:27 ` Bjorn Helgaas [this message]
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=20261109232700.GA345907@bhelgaas \
--to=helgaas@kernel.org \
--cc=Maciej.Grochowski@sony.com \
--cc=Mesih.Kilinc@sony.com \
--cc=alexey.fomenko@intel.com \
--cc=bhelgaas@google.com \
--cc=eauger@redhat.com \
--cc=gloveless@jqluv.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®