Damien Zammit, le jeu. 09 juil. 2020 21:14:59 +1000, a ecrit: > On 9/7/20 9:45 am, Samuel Thibault wrote: > >> + size = vm_page_round(size + palign); > > > >> alloc_size = (1 << (order + PAGE_SHIFT)); > >> npages = vm_page_atop(alloc_size); > > > > I don't think you need to add palign, that could allocate twice as much > > as what you need when the size is equel to palign for instance. The > > alloc_size will be a power of two already, so you just need to bump > > order to vm_page_order(palign) if needed. > > I don't think that is correct either. The physical alignment of the memory > is unrelated to the size requested.
It is in that if you don't ask for enough, you won't be able to fix the alignment, e.g. you want 0x1000 bytes with 0x2000 alignment. If you just ask vm_page_grab_contig for 0x1000 bytes it may return addresses 0x3000-0x4000 which are not 0x2000-aligned. But if you ask for 0x2000 bytes it will be 0x2000-aligned (that's the behavior of the buddy allocator). If we don't want to rely on the buddy allocator behavior we can indeed resort to adding palign to be sure to be able to fix the alignment afterwards. > I've left physical alignment as a TODO as well as pmin != 0, but included it > in the RPC itself so it can be committed even if it doesn't do anything yet. Ok, sure! I'll have a closer look at the patches later. Thanks! Samuel
