2011/4/7 Stéphanie Ouillon <[email protected]>: > 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
