All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Wei Yang <richard.weiyang@gmail.com>,
	akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
	riel@surriel.com, Liam.Howlett@oracle.com, vbabka@suse.cz,
	harry.yoo@oracle.com
Cc: linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [RFC Patch 1/2] selftests/mm: put general ksm operation into vm_util
Date: Fri, 11 Jul 2025 17:37:54 +0200	[thread overview]
Message-ID: <5f7f1281-c75e-4cfe-b51f-8d6ed001200b@redhat.com> (raw)
In-Reply-To: <20250604082145.13800-2-richard.weiyang@gmail.com>

> diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
> index 1357e2d6a7b6..115422e9eb68 100644
> --- a/tools/testing/selftests/mm/vm_util.c
> +++ b/tools/testing/selftests/mm/vm_util.c
> @@ -486,3 +486,74 @@ int close_procmap(struct procmap_fd *procmap)
>   {
>   	return close(procmap->fd);
>   }
> +

I think we should just let all these functions open/close the fds. So 
there will not be a need to pass in the fds.

> +int ksm_use_zero_pages(int ksm_use_zero_pages_fd)
> +{
> +	return write(ksm_use_zero_pages_fd, "1", 1);
> +}
> +
> +int ksm_start_and_merge(int ksm_fd)
> +{
> +	return write(ksm_fd, "1", 1);
 > +}> +
> +int ksm_stop_and_unmerge(int ksm_fd)
> +{
> +	return write(ksm_fd, "2", 1);
> +}

Can we make all these functions return "0" on success? This, way, the 
"write" will be an internal implementation detail.

E.g.,

int ksm_stop_and_unmerge(void)
{
	int ksm_fd = ...
	ssize_t ret;

	...

	ret = write(ksm_fd, "2", 1);
	close(ksm_fd);
	return ret == 1 ? 0 : ret;
}

> +
> +long ksm_get_full_scans(int ksm_full_scans_fd)
> +{
> +	char buf[10];
> +	ssize_t ret;
> +
> +	ret = pread(ksm_full_scans_fd, buf, sizeof(buf) - 1, 0);
> +	if (ret <= 0)
> +		return -errno;
> +	buf[ret] = 0;
> +
> +	return strtol(buf, NULL, 10);
> +}
> +
> +long ksm_get_self_merging_pages(int proc_self_ksm_merging_pages_fd)
> +{
> +	char buf[10];
> +	ssize_t ret;
> +
> +	if (proc_self_ksm_merging_pages_fd < 0)
> +		return proc_self_ksm_merging_pages_fd;
> +
> +	ret = pread(proc_self_ksm_merging_pages_fd, buf, sizeof(buf) - 1, 0);
> +	if (ret <= 0)
> +		return -errno;
> +	buf[ret] = 0;
> +
> +	return strtol(buf, NULL, 10);
> +}
> +
> +long ksm_get_self_zero_pages(int proc_self_ksm_stat_fd)
> +{
> +	char buf[200];
> +	char *substr_ksm_zero;
> +	size_t value_pos;
> +	ssize_t read_size;
> +	unsigned long my_ksm_zero_pages;
> +
> +	if (!proc_self_ksm_stat_fd)
> +		return 0;
> +
> +	read_size = pread(proc_self_ksm_stat_fd, buf, sizeof(buf) - 1, 0);
> +	if (read_size < 0)
> +		return -errno;
> +
> +	buf[read_size] = 0;
> +
> +	substr_ksm_zero = strstr(buf, "ksm_zero_pages");
> +	if (!substr_ksm_zero)
> +		return 0;
> +
> +	value_pos = strcspn(substr_ksm_zero, "0123456789");
> +	my_ksm_zero_pages = strtol(substr_ksm_zero + value_pos, NULL, 10);
> +
> +	return my_ksm_zero_pages;
> +}
> diff --git a/tools/testing/selftests/mm/vm_util.h b/tools/testing/selftests/mm/vm_util.h
> index 9211ba640d9c..99c1b1aa1813 100644
> --- a/tools/testing/selftests/mm/vm_util.h
> +++ b/tools/testing/selftests/mm/vm_util.h
> @@ -95,6 +95,13 @@ static inline int open_self_procmap(struct procmap_fd *procmap_out)
>   	return open_procmap(pid, procmap_out);
>   }
>   
> +int ksm_use_zero_pages(int ksm_use_zero_pages_fd);
> +int ksm_start_and_merge(int ksm_fd);
> +int ksm_stop_and_unmerge(int ksm_fd);
> +long ksm_get_full_scans(int ksm_full_scans_fd);
> +long ksm_get_self_merging_pages(int proc_self_ksm_merging_pages_fd);
> +long ksm_get_self_zero_pages(int proc_self_ksm_stat_fd);

With the fd parameters removed, that interface will look quite neat I think.

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2025-07-11 15:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-04  8:21 [RFC Patch 0/2] selftests/mm: assert rmap behave as expected Wei Yang
2025-06-04  8:21 ` [RFC Patch 1/2] selftests/mm: put general ksm operation into vm_util Wei Yang
2025-07-11 15:37   ` David Hildenbrand [this message]
2025-07-14  2:45     ` Wei Yang
2025-06-04  8:21 ` [RFC Patch 2/2] selftests/mm: assert rmap behave as expected Wei Yang
2025-06-04  8:34   ` Wei Yang
2025-07-11 15:39     ` David Hildenbrand
2025-07-14 14:42       ` Wei Yang
2025-07-14 14:45         ` David Hildenbrand

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=5f7f1281-c75e-4cfe-b51f-8d6ed001200b@redhat.com \
    --to=david@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=harry.yoo@oracle.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=richard.weiyang@gmail.com \
    --cc=riel@surriel.com \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.