linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Ian Rogers' <irogers@google.com>, Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	"Yang Jihong" <yangjihong1@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: RE: [PATCH v1 4/6] perf threads: Move threads to its own files
Date: Thu, 29 Feb 2024 21:59:05 +0000	[thread overview]
Message-ID: <b60c7731b8a84e01a77fea55c31a77b9@AcuMS.aculab.com> (raw)
In-Reply-To: <CAP-5=fUUSpHUUAc3jvJkPAUuuJAiSAO4mjCxa9qUppnqk76wWg@mail.gmail.com>

From: Ian Rogers
> Sent: 27 February 2024 07:24
> 
> On Mon, Feb 26, 2024 at 11:07 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Tue, Feb 13, 2024 at 10:37 PM Ian Rogers <irogers@google.com> wrote:
> > >
> > > Move threads out of machine and move thread_rb_node into the C
> > > file. This hides the implementation of threads from the rest of the
> > > code allowing for it to be refactored.
> > >
> > > Locking discipline is tightened up in this change.
> >
> > Doesn't look like a simple code move.  Can we split the locking
> > change from the move to make the reviewer's life a bit easier? :)
> 
> Not sure I follow. Take threads_nr as an example.
> 
> The old code is in machine.c, so:
> -static size_t machine__threads_nr(const struct machine *machine)
> -{
> -       size_t nr = 0;
> -
> -       for (int i = 0; i < THREADS__TABLE_SIZE; i++)
> -               nr += machine->threads[i].nr;
> -
> -       return nr;
> -}
> 
> The new code is in threads.c:
> +size_t threads__nr(struct threads *threads)
> +{
> +       size_t nr = 0;
> +
> +       for (int i = 0; i < THREADS__TABLE_SIZE; i++) {
> +               struct threads_table_entry *table = &threads->table[i];
> +
> +               down_read(&table->lock);
> +               nr += table->nr;
> +               up_read(&table->lock);
> +       }
> +       return nr;
> +}
> 
> So it is a copy paste from one file to the other. The only difference
> is that the old code failed to take a lock when reading "nr" so the
> locking is added. I wanted to make sure all the functions in threads.c
> were properly correct wrt locking, semaphore creation and destruction,
> etc.  We could have a broken threads.c and fix it in the next change,
> but given that's a bug it could make bisection more difficult.
> Ultimately I thought the locking changes were small enough to not
> warrant being on their own compared to the advantages of having a sane
> threads abstraction.

The lock is pretty much entirely pointless.
All it really does is slow the code down.
The most you could want is:
	nr += READ_ONCE(table->nr);
to avoid any hypothetical data tearing.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  parent reply	other threads:[~2024-02-29 21:59 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  6:37 [PATCH v1 0/6] Thread memory improvements and fixes Ian Rogers
2024-02-14  6:37 ` [PATCH v1 1/6] perf report: Sort child tasks by tid Ian Rogers
2024-02-14 17:24   ` Arnaldo Carvalho de Melo
2024-02-14 17:42     ` Ian Rogers
2024-02-16 20:25       ` Namhyung Kim
2024-02-27  6:39   ` Namhyung Kim
2024-02-27  7:12     ` Ian Rogers
2024-02-28  6:11       ` Namhyung Kim
2024-02-28  7:05         ` Ian Rogers
2024-02-28 22:45           ` Namhyung Kim
2024-02-14  6:37 ` [PATCH v1 2/6] perf trace: Ignore thread hashing in summary Ian Rogers
2024-02-14 17:25   ` Arnaldo Carvalho de Melo
2024-02-14 18:27     ` Ian Rogers
2024-02-14 21:15       ` Ian Rogers
2024-02-14 21:36         ` Ian Rogers
2024-02-14 21:42           ` Ian Rogers
2024-02-16 14:57           ` Arnaldo Carvalho de Melo
2024-02-27  6:55   ` Namhyung Kim
2024-02-14  6:37 ` [PATCH v1 3/6] perf machine: Move fprintf to for_each loop and a callback Ian Rogers
2024-02-14  6:37 ` [PATCH v1 4/6] perf threads: Move threads to its own files Ian Rogers
2024-02-27  7:07   ` Namhyung Kim
2024-02-27  7:24     ` Ian Rogers
2024-02-27 17:31       ` Namhyung Kim
2024-02-27 19:02         ` Ian Rogers
2024-02-27 19:17         ` Arnaldo Carvalho de Melo
2024-02-27 21:42           ` Ian Rogers
2024-02-28  6:39             ` Namhyung Kim
2024-02-28  7:24               ` Ian Rogers
2024-02-28 23:43                 ` Namhyung Kim
2024-02-29  0:31                   ` Ian Rogers
2024-02-29 21:59       ` David Laight [this message]
2024-03-01  0:19         ` Ian Rogers
2024-02-14  6:37 ` [PATCH v1 5/6] perf threads: Switch from rbtree to hashmap Ian Rogers
2024-02-14  6:37 ` [PATCH v1 6/6] perf threads: Reduce table size from 256 to 8 Ian Rogers
2024-02-25 18:50 ` [PATCH v1 0/6] Thread memory improvements and fixes Ian Rogers

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=b60c7731b8a84e01a77fea55c31a77b9@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=peterz@infradead.org \
    --cc=yangjihong1@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;
as well as URLs for NNTP newsgroup(s).