Re: [PATCH v4 5/5] ksm: add mremap selftests for ksm_rmap_walk

[xu.xin16]

> >>> +static void prepare_two_pages(struct global_data *data)
> >>> +{
> >>> +	/* Allocate exactly 2 pages for the test */
> >>> +	data->mapsize = 2 * getpagesize();
> >>> +	data->region = mmap(NULL, data->mapsize, PROT_READ | PROT_WRITE,
> >>> +			    MAP_PRIVATE | MAP_ANON, -1, 0);
> >>> +	if (data->region == MAP_FAILED)
> >>> +		ksft_exit_fail_perror("mmap failed");
> >>> +
> >>> +	/* Fill both pages with identical content to encourage KSM merging */
> >>> +	memset(data->region, 0x77, data->mapsize);
> >>> +}
> >>> +
> >>> +static int mremap_merge_and_migrate(struct global_data *data)
> >>> +{
> >>> +	int ret, pagemap_fd;
> >>> +	void *old_region = data->region;
> >>> +	unsigned long page_sz = getpagesize();
> >>> +
> >>> +	/*
> >>> +	 * Mremap the second page to the first page's location (FIXED).
> >>> +	 * This effectively overwrites the first page, leaving the second page
> >>> +	 * unmapped. The physical page originally at the second page is now
> >>> +	 * mapped at the first page's virtual address.
> >>> +	 */
> >>
> >>
> >> But if there is only a single page, why should it get merged by KSM?
> > 
> > This test runs in multi-threads, So there are not only one page from this thread but
> > also many other pages which are mergeable in all other threads.
> 
> At least the test did not reveal the problem in patch #3 :)
> 
> Can't we just use a single VMA (e.g., 32 pages), fill it with pages of the same
> content, let it merge, then mremap half of it, and then migrate a page etc?
> 

Yes, a single VMA with multiple pages works perfectly and is simpler.

But I'm wondering: should we still support a multi‑process version (Only one work process
do mremap and migrate, while other processes just do check(PFN) ?


What's your opinion? I can drop the multi‑process part if you think it's unnecessary.