Jon Mini wrote: > Personally, I think it would be more intuitive to add a check to the allocation > algorithm that forces it to not consider devices flaged for removal, and > mark each page as free after it comes in. When the bitmap is clean you're done. > However, you're still going to want to count the pages allocated on a device > because it's a lot easier to check the counter than to scan the whole bitmap.
Flagging is how you would have to do it. Counting is fairly useless, since it assumes that, given a bit in the bitmap, you can reverse lookup the page that points to it, and there is not a reverse mapping for this, only a forward (swap mappings swapped out don't write swap metadata to the disk). I guess if you did it over and over again, you could know when you are done. I think that what has to happen is that you are going to have to scan all page mappings in the system to find anyone using the device, and page it in that way. My reasoning on this is that the page mappings exist only in the context of the current process address space. This means that unless you force in each process in turn so that the mappings are relevent to its address space, and then force out what's in core (to a new device) in order to get the pages swapped to the disappearing device, the only really clean way to do it is to rewrite the mappings after manually copying the page from one device to the other using non-swappable pages in the kernel address space as temporary buffers. It's doable, but it's ugly... it's nearly the same problem you'd face if you wanted to defrag kernel memory so that you could do a "contigmalloc" very late in the game, only a bit easier (the kernel does not set ELF attributes to indicate pages containg code or data not in the paging path for you to do this). I'm not positive if you would need to lock the pages you are moving, or not. I think so. The problem is when you have a program that has something like a writeable data page from a shared library, which has been copied via copy-on-write, and then the program that did it forks (this happens all the time in any fork for libc and similar offset fixups). You would end up needing to lock all processes which referenced a page that had been swapped out, with multiple vm_object_t's. Maybe I'm missing something, and there really is a way to get this information back from a known bit in the bitmap... Matt? It was your suggestion? Am I not seeing a function right in front of me? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
