on 06/12/2011 00:22 Alan Cox said the following: > On 12/5/2011 4:02 PM, Andriy Gapon wrote: >> on 05/12/2011 19:58 Alan Cox said the following: >>> On 12/05/2011 07:56, Andriy Gapon wrote: >>>> Pages should be marked busy only for some special occasions, wired pages are >>>> not >>>> normally busy; the correct explanation is quite a bit longer than this, the >>>> comment in the code explains VPO_BUSY as "page is in transit". Right now this >>>> flag doesn't seem tom affect vboxdrv code but it may lead to surprises when >>>> some >>>> parts of code that are incorrect now are re-implemented properly: >>>> http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 >>> VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From >>> the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): >>> >>> * VM_ALLOC_NOOBJ page is not associated with an object and >>> * should not have the flag VPO_BUSY set >> Ah, oops, forgot about this. >> >>> With regard to the message that the above link points to, I suspect that the >>> introduction of vm_page_alloc_contig() can be used to address the first problem >>> that you point out. Specifically, one or more OBJT_PHYS vm objects could be >>> created and passed to vm_map_find() and then vm_page_alloc_contig() could be >>> used to fill these vm objects with memory. >> That's exactly what I was trying to do when I encountered a need for >> VM_ALLOC_NOOBJ - my object was not NULL. >> Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a >> user map (or a few of them) at the same time? >> > > Yes, it is. Thank you! And another question - what would you recommend as a substitute for vm_page_alloc_contig in FreeBSD versions that do not have it? All I can think of is essentially replicating kmem_alloc_contig + contigmapping and allowing a user-specified object to be used in place of kernel_object. -- Andriy GaponReceived on Mon Dec 05 2011 - 21:38:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC