Re: [PATCH v4 0/7] PCI: Resource placement algorithm fixe

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

On Fri, 23 Oct 2026, Maciej Grochowski wrote:

> Hi Ilpo,
> 
> Thank you for the v4 patches, and sorry for the delayed feedback on v2.
> Mesih (CC'd) tested your full v2 seven-patch series on our
> Switchtec-based platform, with positive results.
> 
> The test used a backport to our Linux 6.18.20 platform tree, with
> additional allocator prerequisites included and our local
> max() -> ALIGN() workaround reverted. This is therefore feedback
> on the backported series rather than a test on its upstream base.

Hi,

Okay, thanks for the test.

> The kernel boots successfully, all eight endpoints have
> BAR0, BAR2 and BAR4 assigned, and switchtec detects all nine
> switches. No BAR assignment failures were observed in the boot log.
> 
> One difference from my original report is that BAR4 is enabled in
> this test; the earlier report described a configuration with BAR4
> suppressed. The total BAR allocation across the eight endpoints
> is now 288 MiB.
> 
> We also compared /proc/iomem against the earlier kernel carrying
> our ALIGN() workaround. The enclosing prefetchable bridge window
> is 387 MiB with the backported v2 series, versus 384 MiB with the
> workaround, while the total endpoint BAR allocation is unchanged.
> So this test shows successful assignment, but no address-space
> reduction for this configuration. I do not yet have the detailed
> placement traces needed to explain the 3 MiB difference.

You want to look at the place where the window is sized and work 
backwards why pbus_size_mem() calculated that size. In the printouts 
(for non-assigned bridge window), the start address is the alignment
and size is end-start+1. If the window has an optional part, the add_size 
printout is there but otherwise the prints are a bit scarse.

When trying to debug pci resource issues, dyndbg might be helpful here and 
there so I always add this to kernel's cmdline myself:

dyndbg="file drivers/pci/*.c +p"

It will give a bit more information about resource decisions in dmesg and 
their basis (things could be better in many areas still but most of the 
missing details are inferrable, e.g., what resources are considered 
optional, etc.).

> We will now also test v4 and report back. Could the changes since v2
> affect this window-size result, or is this amount of padding expected
> for this topology? Please let us know which logs or allocator traces
> would be most useful to collect with the v4 test.

I suggest you wait until I send the next version which addresses the 
problems sashiko located in v4. I've basically tested the update locally 
and should get to sending it today or tomorrow.

I normally use iomem, dmesg with pci dyndbg on, and lspci.

Generally, I normally look /proc/iomem for quick overview of the layout. 
If you have something to compare with, it's even easier to see what 
changed and focus on those. E.g. you know commit x broke something so a 
kernel before that commit or the problematic commit reverted vs the broken 
one. The less there are other changes in between, the less noisy the 
diff is.

lspci is mainly needed to map resources to BAR/ROM/VF BAR as the iomem 
format conceal what the resource is. Again, diffing pre (when available) 
vs post saves lots of time in focusing on the relevant bits.

For diffing dmesgs, I've this tool:

$ cat dmesg-diff 
#!/bin/bash
 
diff -u <(cut -d ']' -f 2- "$1" | cut -b 2-) <(cut -d ']' -f 2- "$2" | cut -b 2-)

-- 
 i.