Messages in this thread | | | Subject | Re: Atomic operation for physically moving a page (for memory defragmentation) | From | Valdis.Kletnieks@vt ... | Date | Fri, 18 Jun 2004 23:34:06 -0400 |
| |
On Fri, 18 Jun 2004 20:15:36 PDT, Ashwin Rao said:
> The problem is the memory fragmentation. The code i am > writing is for the memory defragmentation as proposed > by Daniel Phillips, my project partner Alok mooley has > given mailed a simple prototype in the mid of feb.
OK.. Now we're getting somewhere. ;) (Feel free to ignore the rest - I'm *not* a memory management expert, but a few thoughts come to mind - things that might help the real experts answer the question..)
> > (*) Yes, I know the BKL isn't something you want to > > grab if you can help it. > > Isnt it a bad idea to take the BKL, the performance of > SMP systems will drastically be hampered.
As I noted - not something you *want* to grab. But sometimes, especially when it's in error recovery, code may want to be able to tell *everything* else to stay put for a moment while it figures out what it needs to do next...
> The way we work is as follows > Initially a block is selected which can be moved i.e > pages on lru or free and the pages are moved to a
Out of curiosity, have you done any modeling to see how often you need to move a page to coalesce holes and keep fragmentation down? The "best" solution will quite likely be vastly different if it's something that needs to be done only as a "last resort" (i.e. order-N allocations are failing for non-large N), or if it's something that works best if it's being done several times a second during normal system operation, etc....
> suitable free pages. The main problem arises during > the copying and updation process. All the ptes are to > updates. a method similar to try_to_unmap_one is used > to identify the ptes and the physical address is > updated.
> The problem we are facing is to maintain the atomicity > of this operation on SMP boxes.
Ahh.. Is there one thing in particular that causes the issues? It may make sense to grab whatever lock usually controls that, at least as a first-cut (what lock(s) are used by try_to_unmap_one, for instance). There's probably already a suitable lock, already grabbed by whatever code is interfering with what your code is doing..
[unhandled content-type:application/pgp-signature] | |