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

[HATAYAMA Daisuke]

From: "Hatayama, Daisuke" <d.hatayama at 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