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
next prev parent 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).