linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Jinjiang Tu <tujinjiang@huawei.com>,
	akpm@linux-foundation.org, shr@devkernel.io, hannes@cmpxchg.org,
	riel@surriel.com, wangkefeng.wang@huawei.com,
	sunnanyong@huawei.com, linux-mm@kvack.org
Subject: Re: [PATCH v3 2/3] selftest/mm: ksm_functional_tests: refactor mmap_and_merge_range()
Date: Wed, 27 Mar 2024 12:31:26 +0100	[thread overview]
Message-ID: <c260c872-987a-4f81-8894-b82e65abb232@redhat.com> (raw)
In-Reply-To: <20240327060922.1484395-3-tujinjiang@huawei.com>

On 27.03.24 07:09, Jinjiang Tu wrote:
> In order to extend test_prctl_fork() and test_prctl_fork_exec() to make
> sure that deduplication really happens, mmap_and_merge_range() needs to be
> refactored.
> 
> Firstly, mmap_and_merge_range() will be called with no need to call enable
> KSM by madvise or prctl. So, switch the 'bool use_prctl' parameter to enum
> ksm_merge_mode.
> 
> Secondly, mmap_and_merge_range() will be called in child process in the
> two testcases, it isn't appropriate to call ksft_test_result_{fail, skip},
> because the global variables ksft_{fail, skip} aren't consistent with the
> parent process. Thus, convert calls of ksft_test_result_{fail, skip} to
> ksft_print_msg() and return differrent error according to the two cases.
> The callers of mmap_and_merge_range() then call ksft_test_result_{fail,
> skip} according to the return value. Introduce mmap_and_merge_err_print()
> helper to make it easier.
> 
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
> ---

[...]

>   
> @@ -209,14 +228,28 @@ static char *mmap_and_merge_range(char val, unsigned long size, int prot,
>   	 * accounted differently (depending on kernel support).
>   	 */
>   	if (val && !get_my_merging_pages()) {
> -		ksft_test_result_fail("No pages got merged\n");
> +		ksft_print_msg("No pages got merged\n");
>   		goto unmap;
>   	}
>   
>   	return map;
>   unmap:
>   	munmap(map, size);
> -	return MAP_FAILED;
> +	return err_map;
> +}
> +
> +static inline int mmap_and_merge_err_print(char *map)
> +{
> +	int ret = -1;
> +
> +	if (map == MAP_MERGE_FAIL)
> +		ksft_test_result_fail("Merging memory failed");
> +	else if (map == MAP_MERGE_FAIL)

MAP_MERGE_SKIP

> +		ksft_test_result_skip("Merging memory skiped");

"skipped"

> +	else
> +		ret = 0;
> +
> +	return ret;
>   }
>   
>   static void test_unmerge(void)
> @@ -226,8 +259,8 @@ static void test_unmerge(void)
>   
>   	ksft_print_msg("[RUN] %s\n", __func__);
>   
> -	map = mmap_and_merge_range(0xcf, size, PROT_READ | PROT_WRITE, false);
> -	if (map == MAP_FAILED)
> +	map = mmap_and_merge_range(0xcf, size, PROT_READ | PROT_WRITE, KSM_MERGE_MADVISE);
> +	if (mmap_and_merge_err_print(map))

I like the concept.

The following would be cleaner and result in less churn:

1) Rename mmap_and_merge_range() to "__mmap_and_merge_range()"

2) Introduce a new mmap_and_merge_range()

static inline char *mmap_and_merge_range(char val, unsigned long size,
		int prot, enum ksm_merge_mode mode)
{
	char *map = __mmap_and_merge_range(val, size, prot, mode);	
	char *ret = MAP_FAILED;

	if (map == MAP_MERGE_FAIL)
		ksft_test_result_fail("Merging memory failed");
	else if (map == MAP_MERGE_SKIP)
		ksft_test_result_skip("Merging memory skipped");
	else
		ret = map;

	return ret;
}

3) Use __mmap_and_merge_range() in patch #3.

No need to adjust any existing callers of mmap_and_merge_range().

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-03-27 11:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27  6:09 [PATCH v3 0/3] mm/ksm: fix ksm exec support for prctl Jinjiang Tu
2024-03-27  6:09 ` [PATCH v3 1/3] " Jinjiang Tu
2024-03-27  9:15   ` David Hildenbrand
2024-03-27  6:09 ` [PATCH v3 2/3] selftest/mm: ksm_functional_tests: refactor mmap_and_merge_range() Jinjiang Tu
2024-03-27 11:31   ` David Hildenbrand [this message]
2024-03-27  6:09 ` [PATCH v3 3/3] selftest/mm: ksm_functional_tests: extend test case for ksm fork/exec Jinjiang Tu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c260c872-987a-4f81-8894-b82e65abb232@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@surriel.com \
    --cc=shr@devkernel.io \
    --cc=sunnanyong@huawei.com \
    --cc=tujinjiang@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox