[...] >> [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
