Hi Kamezawa-san,

Thank you for your quick response. And sorry for slow response.

KAMEZAWA Hiroyuki wrote:

> Hideo AOKI <haoki@redhat.com> wrote:
> 
>>Since __vm_enough_memory() doesn't know zone and cpuset information,
>>we have to guess proper value of lowmem_reserve in each zone
>>like I did in calculate_totalreserve_pages() in my patch.
>>Do you think that we can do this calculation every time?
>>
>>If it is good enough, I'll make revised patch.
>>
> 
> I just thought to show "how to calculate" in unified way is better.

I got it.

> Do you have a detailed comparison of test result with and without this patch ?

Yes. I have test logs and attach them to this e-mail.

The logs are verbose output of my test kernel module which I already
sent to lkml.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114428121522349&w=2

Test machine was i386 4GB memory PC. I didn't use swap region.


Let me explain a few things about the log.

* 2.6.17-rc1-mm1

HIGH: <active 18220><inactive 12278><free 1419><sum 31917><present 622220>
NORMAL: <active 1618><inactive 2293><free 1397><sum 5308><present 225280>

   The test module consumes free pages until the number of free pages
   is less than pages_high.


<buf 3916><cache 31785><slab reclaim 1550><swap 0> <+ 1> <target 33336>

   This line shows the status of memory just before the module calls
   __vm_enough_memory(). Meaning of each item is below.

     buf:            bufferram
     cache:          page cache
     slab reclaim:   slab_reclaim_pages
     swap:           nr_swap_pages
     +:              margin
     target:         the number of pages to ask __vm_enough_memory()


Test MAY be <failed>.

   This line shows __vm_enough_memory() returned success.


Please let me know if you have any questions and suggestions.

Regards,
Hideo Aoki

---
Hideo Aoki, Hitachi Computer Products (America) Inc.