Re: physical memory allocator in DragonFly BSD

[Venkatesh Srinivas <me@xxxxxxxxxxxxxxxxxxx>]

2011/4/7 Stéphanie Ouillon <stephanie@minet.net>:
> Hello,
>
> Venkatesh Srinivas made a comment on my gsoc application about implementing
> virtio drivers ( by the way, thank you about it ! I added some lines and
> time for the balloon driver ).
> I copy it :
> "Just a warning -- the virtio balloon driver will likely involve a good
> amount of porting work; the NetBSD UVM is rather different than the DFly VM.
> The mechanism by which the balloon consumes "physical" memory will likely be
> different. On NetBSD, it probably uses something like uvm_pglistalloc()... I
> don't think we have a good contiguous physical memory allocator, so you
> might have to be careful."
>
> When NetBSD uses uvm_pglistalloc and uvm_pglistfree (I checked the code),
> DragonFly BSD will likely use contigmalloc and contigfree (like in FreeBSD)
> to deal with contiguous physical allocation.
> Well, I searched for some information, but could you explain me why I should
> be cautious with the physical memory allocation on DragonFly BSD, do you
> have encoutered any problem with it ?
>

Hi,

No problems as far as I know, just that it was something to keep in
mind (that we didn't have the uvm_ routines).

I have noticed after a while of system uptime, contigmalloc has
difficulty finding larger chunks of contiguous physical memory; this
problem shows up fairly often in the USB code, where finding 64KB USB
DMAable chunks fails after a few days of uptime. Something to keep in
mind is that you might have difficulty finding ~64K+ contig memory
chunks to balloon... (maybe not anymore).

Thanks,
-- vs