Re: [RFC] memory defragmentation to satisfy high order allocations

[Hirokazu Takahashi <taka@valinux.co.jp>]

Hello, Marcelo.

Generic memory defragmentation will be very nice for me to implement
hugetlbpage migration, as allocating a new hugetlbpage is a hard job.

> For the "defragmentation" operation we want to do an "easy" try - ie if we
> can't remap giveup.
> 
> I feel we should try to "untie" the code which checks for remapping availability / 
> does the remapping from the page migration - so to be able to share the most 
> code between it and other users of the same functionality. 

I think it's possible to introduce non-wait mode to the migration code,
as you may expect. Shall I implement it?

> Curiosity: How did you guys test the migration operation? Several threads on 
> several processors operating on the memory, etc? 

I always test it with the zone hotplug emulation patch, which Mr.Iwamoto
has made. I usually run following jobs concurrently while zones are added
and removed repeatedly on a SMP machine.
      - making linux kernel
      - copying file trees.
      - overwriting file trees.
      - removing file trees
      - some pages are swapped out automatically:)

And Mr.Iwamoto has some small programs to check any kind of page
can be migrated. The programs repeat one of following actions:
    - read/write files .
    - use MAP_SHARED and MAP_PRIVATE mmap()'s and read/write there.
    - use Direct I/O.
    - use AIO.
    - fork to have COW pages.
    - use shmem.
    - use sendfile.

> Cool. I'll take a closer look at the relevant parts of memory hotplug patches 
> this weekend, hopefully. See if I can help with testing of these patches too.

Any comments are very welcome.

Thank you,
Hirokazu Takahashi.






--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>