Linux Test Project
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] kernel/irq: Add irqbalance01
Date: Fri, 8 Oct 2021 10:23:23 +0200	[thread overview]
Message-ID: <YV//+xhzYHN5349v@yuki> (raw)
In-Reply-To: <20210916123248.4974-1-rpalethorpe@suse.com>

Hi!
> +	/* Read the CPU affinity masks for each IRQ. The first CPU is in the
> +	 * right most (least significant) bit. See bitmap_string() in the kernel
> +	 * (%*pb)
> +	 */
> +	for (row = 0; row < nr_irqs; row++) {
> +		sprintf(path, "/proc/irq/%u/smp_affinity", irq_ids[row]);
> +		buf = read_proc_file(path);
> +		c = buf;
> +		col = 0;
> +
> +		while (*c != '\0')
> +			c++;

A minor nit, we alredy know the lenght, but we do not return it from the
read_proc_file() we may as well change this so taht the read_proc_file
returns both buffer pointer and the size. E.g. add size_t *len parameter
to the read_proc_file() and set it if it's not NULL.

Other than that the parsing looks good now.

> +static void evidence_of_change(void)
> +{
> +	size_t row, col, changed = 0;
> +
> +	for (row = 0; row < nr_irqs; row++) {
> +		for (col = 0; col < nr_cpus; col++) {
> +			if (!irq_stats[row * nr_cpus + col])
> +				continue;
> +
> +			if (irq_affinity[row * nr_cpus + col] == ALLOW)
> +				continue;
> +
> +			changed++;
> +		}
> +	}
> +
> +	tst_res(changed ? TPASS : TFAIL,
> +		"Heuristic: Detected %zu irq-cpu pairs have been dissallowed",
> +		changed);
> +}

I'm still unusure about this part though.

The test fails on my workstation where the IRQs are nicely distributed
by the hardware/BIOS.

Maybe we should check if IRQs are distributed somehow evenly and PASS
the test if that is the case as well.

In my case there is 27 IRQs, 18 of them have non-zero counters and there
is 12 CPUs. For active IRQs that gives 18/12 = 1.5 IRQ per CPU and there
are 7 CPUs that handle 2 IRQs, 4 CPUs that handle 1 IRQ and 1 CPU that
doesn't handle anything. I wonder if we can figure out some kind of
heuristic, but I guess that in the end it wouldn't be worth the effort.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2021-10-08  8:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210909140911.44EC9A4308@relay2.suse.de>
2021-09-16 12:32 ` [LTP] [PATCH v2] kernel/irq: Add irqbalance01 Richard Palethorpe
2021-09-16 12:32   ` Richard Palethorpe via ltp
2021-09-16 20:55   ` Petr Vorel
2021-09-16 20:55     ` Petr Vorel
2021-10-08  8:23   ` Cyril Hrubis [this message]
2021-10-11  9:22     ` Richard Palethorpe
2021-08-31  9:39 [LTP] [PATCH] " Richard Palethorpe
2021-08-31 11:44 ` [LTP] [PATCH v2] " Richard Palethorpe
2021-08-31 12:01   ` Petr Vorel
2021-09-09 12:41   ` Cyril Hrubis
2021-09-09 12:41     ` Cyril Hrubis
2021-09-09 14:09   ` Cyril Hrubis
2021-09-09 14:09     ` Cyril Hrubis

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=YV//+xhzYHN5349v@yuki \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=rpalethorpe@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