bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnumach: [PATCH] - irq as a mach device


From: Samuel Thibault
Subject: Re: gnumach: [PATCH] - irq as a mach device
Date: Thu, 9 Jul 2020 14:40:23 +0200
User-agent: NeoMutt/20170609 (1.8.3)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]