Re: Atomic operation for physically moving a page (for memory defragmentation)

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

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..


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]