From: Ian Rogers <irogers@google.com>
To: 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-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 11:02:57 -0800 [thread overview]
Message-ID: <CAP-5=fVmrrkMdNwYPqYbK_M3AKQMqoXEi4whbzoUeoj-ROxzeA@mail.gmail.com> (raw)
In-Reply-To: <CAM9d7chXtmfaC73ykiwn+RqJmy5jZFWFaV_QNs10c_Td+zmLBQ@mail.gmail.com>
On Tue, Feb 27, 2024 at 9:31 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> 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.
I'll see what I can split out in v2. I don't think findnew will change
and the nr change is trivial. In the previous code the lock is taken
before calling __machine__findnew_thread, which doesn't make sense
when we try to abstract inside of threads, where it should
take/release the lock in the threads and not the machine code. Moving
the lock to __machine__findnew_thread doesn't really make sense as the
__ implies the lock is already held.
Thanks,
Ian
> Thanks,
> Namhyung
next prev parent reply other threads:[~2024-02-27 19:03 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 [this message]
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='CAP-5=fVmrrkMdNwYPqYbK_M3AKQMqoXEi4whbzoUeoj-ROxzeA@mail.gmail.com' \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bpf@vger.kernel.org \
--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).