[...]
[Patch 5] Track-alignment-explicitly Almost the same as the previous, just changed priority from r->align to r->sum when setting start address of root regions.
I guess there are more chances to fit memory regions if we try place regions with higher r->sum like it was before. Consider default config #define BUILD_PCIMEM_START 0xe0000000 #define BUILD_PCIMEM_END 0xfec00000
Image we have 1 pref. mem. region of 128MB. And many small memory regions which take rest of available 492MB - 128MB If we have alignment priority. PCI pref memory region will start from F000 0000 and PCI memoryregion will start from 0xe0000000 and do not fit.
The section with the lowest alignment would get allocated first and be at a higher address. So, in your example, the regular memory region would be assigned 0xe8000000 and then pref mem would be assigned 0xe0000000.
Your example is why alignment should be used instead of size. If size is used, then what you cite above occurs (pref mem has the lower size and is thus allocated first at the higher address).
Ahh the lowest alignment! In other words if we go from PCIMEM_START to PCIMEM_END we first assign address range for the region with the largest PCI resource size (highest alignment). I see. I will put it back then.
....
On patch 10, it would be preferable to separate the dynamic calculation of sum/alignment changes from the 64bit support. Otherwise, the core algorithm of patch 10 looks okay. Though it seems like the code is recalculating sum/alignment more than needed, and I think the list manipulation in pci_region_migrate_64bit_entries could be streamlined.
Right, sum/alignment recalculation is important for migration. Will split it and submit new series.
Thanks, Alexey