From: Petr Vorel <pvorel@suse.cz>
To: Wei Gao <wegao@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1] swapping01.c: Reporting /proc/meminfo before test and at the moment of the failure
Date: Tue, 12 Dec 2023 18:29:29 +0100 [thread overview]
Message-ID: <20231212172929.GA629121@pevik> (raw)
In-Reply-To: <20231210094339.26971-1-wegao@suse.com>
Hi Wei,
nit: the subject is:
"swapping01.c: Reporting /proc/meminfo before test and at the moment of the failure"
This is way too long, please make it shorter (it should be up to 72 chars),
you can write more at other lines (not everything have to be on the subject).
> Signed-off-by: Wei Gao <wegao@suse.com>
> ---
> testcases/kernel/mem/swapping/swapping01.c | 24 +++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
> diff --git a/testcases/kernel/mem/swapping/swapping01.c b/testcases/kernel/mem/swapping/swapping01.c
> index fc225e4a6..07d89f44b 100644
> --- a/testcases/kernel/mem/swapping/swapping01.c
> +++ b/testcases/kernel/mem/swapping/swapping01.c
> @@ -60,6 +60,17 @@ static long mem_over_max;
> static pid_t pid;
> static unsigned int start_runtime;
NOTE: we have tst_available_mem() and tst_available_swap() in
lib/tst_memutils.c. Wouldn't be they enough? Or other line from /proc/meminfo
(new function would need to be added)? I'm not sure myself.
Also, is it really needed to print both /proc/meminfo and /proc/PID/status?
And if it's needed, why other testcases/kernel/mem/ tests don't need it?
Notes below are if we decide that we want this (I'd like to hear others).
> +static void print_meminfo(char *path)
You use print_meminfo() for printing /proc/meminfo and /proc/PID/status.
Instead, there could be a generic function safe_print_file(char *path) either in
safe_macros.c or tst_print_file(char *path) in tst_safe_file_at.c (I slightly
prefer the first, there is a mess with files in lib/*.c, there are way too many
files with just few functions).
The function would also print TINFO message which file is printing.
And then, in lib/tst_memutils.c would be tst_print_meminfo() which would call
safe_print_file("/proc/meminfo") and tst_print_status(pid_t pid), which would do
sprintf(proc_status_path, "/proc/%d/status", pid) and call safe_print_file()
with the result.
NOTE: you need to add also function signature to corresponding include/*.h file.
This should be done as a separate commit, using function in swapping01.c would
be as a separate commit.
> +{
> + FILE *file;
> + char line[PATH_MAX];
> +
> + file = SAFE_FOPEN(path, "r");
> + while (fgets(line, sizeof(line), file))
> + tst_res(TINFO, "%s", line);
> + SAFE_FCLOSE(file);
> +}
> +
> static void test_swapping(void)
> {
> #ifdef TST_ABI32
> @@ -84,6 +95,8 @@ static void test_swapping(void)
> switch (pid = SAFE_FORK()) {
> case 0:
> do_alloc(0);
> + tst_res(TINFO, "Meminfo before check:");
IMHO this TINFO should be removed (TINFO in the printing function is enough).
> + print_meminfo("/proc/meminfo");
> do_alloc(1);
> exit(0);
> default:
> @@ -108,9 +121,11 @@ static void do_alloc(int allow_raise)
> long mem_count;
> void *s;
> - if (allow_raise == 1)
> + if (allow_raise == 1) {
> + init_meminfo();
Why this? You haven't mentioned it in the commit message.
> tst_res(TINFO, "available physical memory: %ld MB",
> mem_available_init / 1024);
> + }
...
> swapped = SAFE_READ_PROC_STATUS(pid, "VmSwap:");
> if (swapped > mem_over_max) {
> + tst_res(TINFO, "Heavy swapping detected, print meminfo:");
Again, I'd prefer generic message in print_meminfo() (on a single place).
IMHO it will be obvious that first print is before test and the second after.
Kind regards,
Petr
> + print_meminfo("/proc/meminfo");
> + tst_res(TINFO, "Heavy swapping detected, print proc status:");
> + sprintf(proc_status_path, "/proc/%d/status", pid);
> + print_meminfo(proc_status_path);
> kill(pid, SIGCONT);
> tst_brk(TFAIL, "heavy swapping detected: "
> "%ld MB swapped.", swapped / 1024);
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-12-12 17:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 9:43 [LTP] [PATCH v1] swapping01.c: Reporting /proc/meminfo before test and at the moment of the failure Wei Gao via ltp
2023-12-12 17:29 ` Petr Vorel [this message]
2023-12-14 6:33 ` [LTP] [PATCH v2 0/2] Add tst_print_meminfo function in swapping01 Wei Gao via ltp
2023-12-14 6:33 ` [LTP] [PATCH v2 1/2] tst_memutils.c: Add tst_print_meminfo function Wei Gao via ltp
2023-12-14 6:33 ` [LTP] [PATCH v2 2/2] swapping01.c: Reporting /proc/meminfo during test Wei Gao via ltp
2023-12-14 7:13 ` [LTP] [PATCH v3 0/2] Add tst_print_meminfo function into swapping01 Wei Gao via ltp
2023-12-14 7:13 ` [LTP] [PATCH v3 1/2] tst_memutils.c: Add tst_print_meminfo function Wei Gao via ltp
2023-12-15 18:57 ` Petr Vorel
2023-12-18 3:41 ` Li Wang
2023-12-18 3:51 ` Li Wang
2023-12-18 4:39 ` Petr Vorel
2023-12-18 4:30 ` Petr Vorel
2023-12-18 7:20 ` Li Wang
2023-12-14 7:13 ` [LTP] [PATCH v3 2/2] swapping01.c: Reporting /proc/meminfo during test Wei Gao via ltp
2023-12-18 7:37 ` Li Wang
2023-12-18 12:22 ` [LTP] [PATCH v4 0/2] Add tst_print_meminfo function into swapping01 Wei Gao via ltp
2023-12-18 12:22 ` [LTP] [PATCH v4 1/2] tst_memutils.c: Add tst_print_meminfo function Wei Gao via ltp
2023-12-18 13:24 ` Petr Vorel
2023-12-18 12:22 ` [LTP] [PATCH v4 2/2] swapping01.c: Reporting /proc/meminfo during test Wei Gao via ltp
2023-12-18 13:34 ` Petr Vorel
2023-12-18 13:47 ` Petr Vorel
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=20231212172929.GA629121@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
--cc=wegao@suse.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