linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
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-perf-users@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH v1 4/6] perf threads: Move threads to its own files
Date: Tue, 27 Feb 2024 09:31:33 -0800	[thread overview]
Message-ID: <CAM9d7chXtmfaC73ykiwn+RqJmy5jZFWFaV_QNs10c_Td+zmLBQ@mail.gmail.com> (raw)
In-Reply-To: <CAP-5=fUUSpHUUAc3jvJkPAUuuJAiSAO4mjCxa9qUppnqk76wWg@mail.gmail.com>

On Mon, Feb 26, 2024 at 11:24 PM Ian Rogers <irogers@google.com> wrote:
>
> 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.

I can see some other differences like machine__findnew_thread()
which I think is due to the locking change.  Maybe we can fix the
problem before moving the code and let the code move simple.

Thanks,
Namhyung

  reply	other threads:[~2024-02-27 17:31 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 [this message]
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
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=CAM9d7chXtmfaC73ykiwn+RqJmy5jZFWFaV_QNs10c_Td+zmLBQ@mail.gmail.com \
    --to=namhyung@kernel.org \
    --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=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).