Re: [PATCH v2] makedumpfile: request the kernel do page scans

HATAYAMA Daisuke
2012-11-22T14:07:19Z

From: "Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com>
Subject: RE: [PATCH v2] makedumpfile: request the kernel do page scans
Date: Thu, 22 Nov 2012 01:43:39 +0000

[...]

>> +/*
>> + * limit the size of the pfn list to this many pfn_element structures
>> + */
>> +#define MAX_PFN_LIST 10000
>> +
>> +/*
>> + * one element in the pfn_list
>> + */
>> +struct pfn_element {
>> + unsigned long pfn;
>> + unsigned long order;
>> +};
>> +
>> +/*
>> + * a request for finding pfn's that can be excluded from the dump
>> + * they may be pages of particular types or free pages
>> + */
>> +struct pfn_list_request {
>> + int request; /* PL_REQUEST_FREE PL_REQUEST_EXCLUDE or
>> */
>> + /* PL_REQUEST_MEMMAP */
>> + int debug;
>> + unsigned long paddr; /* mem_map address for
>> PL_REQUEST_EXCLUDE */
>> + unsigned long pfn_start;/* pfn represented by paddr */
>> + unsigned long pgdat_paddr; /* for PL_REQUEST_FREE */
>> + unsigned long pgdat_vaddr; /* for PL_REQUEST_FREE */
>> + int node; /* for PL_REQUEST_FREE */
>> + int exclude_bits; /* for PL_REQUEST_EXCLUDE */
>> + int count; /* for PL_REQUEST_EXCLUDE */
>> + void *reply_ptr; /* address of user's pfn_reply, for reply
>> */
>
> How about passing bitmap instead of lists and making kernel side unset bits
> corresponding to unnecessary pages? It's less coping and constant.
>

Again, there's also small memory issue. makedumpfile v1.5.1 calculates
cyclic buffer size automatically from MemFree in /proc/meminfo. It's
40% of MemFree. There are two bitmaps so 80% is used in total.

Now, if passing bitmap as usual, copy_from_user() would be used. But
then, kernel space needs to prepare buffer of the cyclic buffer
size. It's 120% in total.

Alternatively, my idea is to export bitmap from kernel-space, and from
makedumpfile, mmap it, read it and then updates it each time one cycle
ends.

Thanks.
HATAYAMA, Daisuke