From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Riccardo Mancini <rickyman7@gmail.com>
Cc: Ian Rogers <irogers@google.com>,
Namhyung Kim <namhyung@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@redhat.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com>
Subject: Re: [RFC PATCH 01/10] perf workqueue: threadpool creation and destruction
Date: Wed, 14 Jul 2021 11:16:04 -0300 [thread overview]
Message-ID: <YO7xpFg0F5Fv/7sI@kernel.org> (raw)
In-Reply-To: <46f9e291af3d87c212d279717d56eeab4cbfde68.1626177381.git.rickyman7@gmail.com>
Em Tue, Jul 13, 2021 at 02:11:12PM +0200, Riccardo Mancini escreveu:
> The workqueue library is made up by two components:
> - threadpool: handles the lifetime of the threads
> - workqueue: handles work distribution among the threads
>
> This first patch introduces the threadpool, starting from its creation
> and destruction functions.
> Thread management is based on the prototype from Alexey:
> https://lore.kernel.org/lkml/cover.1625227739.git.alexey.v.bayduraev@linux.intel.com/
>
> Each thread in the threadpool executes the same function (aka task)
> with a different argument tidx.
> Threads use a pair of pipes to communicate with the main process.
> The threadpool is static (all threads will be spawned at the same time).
> Future work could include making it resizable and adding affinity support
> (as in Alexey prototype).
>
> Suggested-by: Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com>
> Signed-off-by: Riccardo Mancini <rickyman7@gmail.com>
> ---
> tools/perf/util/Build | 1 +
> tools/perf/util/workqueue/Build | 1 +
> tools/perf/util/workqueue/threadpool.c | 175 +++++++++++++++++++++++++
> tools/perf/util/workqueue/threadpool.h | 19 +++
> 4 files changed, 196 insertions(+)
> create mode 100644 tools/perf/util/workqueue/Build
> create mode 100644 tools/perf/util/workqueue/threadpool.c
> create mode 100644 tools/perf/util/workqueue/threadpool.h
>
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index 2d4fa13041789cd6..c7b09701661c869d 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -180,6 +180,7 @@ perf-$(CONFIG_LIBBABELTRACE) += data-convert-bt.o
> perf-y += data-convert-json.o
>
> perf-y += scripting-engines/
> +perf-y += workqueue/
>
> perf-$(CONFIG_ZLIB) += zlib.o
> perf-$(CONFIG_LZMA) += lzma.o
> diff --git a/tools/perf/util/workqueue/Build b/tools/perf/util/workqueue/Build
> new file mode 100644
> index 0000000000000000..8b72a6cd4e2cba0d
> --- /dev/null
> +++ b/tools/perf/util/workqueue/Build
> @@ -0,0 +1 @@
> +perf-y += threadpool.o
> diff --git a/tools/perf/util/workqueue/threadpool.c b/tools/perf/util/workqueue/threadpool.c
> new file mode 100644
> index 0000000000000000..70c67569f956a3e2
> --- /dev/null
> +++ b/tools/perf/util/workqueue/threadpool.c
> @@ -0,0 +1,175 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <stdlib.h>
> +#include <stdio.h>
> +#include <unistd.h>
> +#include <errno.h>
> +#include <string.h>
> +#include "debug.h"
> +#include "asm/bug.h"
> +#include "threadpool.h"
> +
> +enum threadpool_status {
> + THREADPOOL_STATUS__STOPPED, /* no threads */
> + THREADPOOL_STATUS__ERROR, /* errors */
> + THREADPOOL_STATUS__MAX
> +};
> +
> +struct threadpool_struct {
Can this be just 'struct threadpool'? I think its descriptive enough:
> + int nr_threads; /* number of threads in the pool */
> + struct thread_struct *threads; /* array of threads in the pool */
> + struct task_struct *current_task; /* current executing function */
> + enum threadpool_status status; /* current status of the pool */
> +};
> +
> +struct thread_struct {
> + int idx; /* idx of thread in pool->threads */
> + pid_t tid; /* tid of thread */
> + struct threadpool_struct *pool; /* parent threadpool */
> + struct {
> + int from[2]; /* messages from thread (acks) */
> + int to[2]; /* messages to thread (commands) */
> + } pipes;
> +};
This one, since we have already a 'struct thread' in tools/perf, to
represent a PERF_RECORD_FORK, perhaps we can call it 'struct threadpool_entry'?
> +
> +/**
> + * init_pipes - initialize all pipes of @thread
> + */
> +static void init_pipes(struct thread_struct *thread)
> +{
> + thread->pipes.from[0] = -1;
> + thread->pipes.from[1] = -1;
> + thread->pipes.to[0] = -1;
> + thread->pipes.to[1] = -1;
> +}
> +
> +/**
> + * open_pipes - open all pipes of @thread
> + */
> +static int open_pipes(struct thread_struct *thread)
Here please:
threadpool_entry__open_pipes()
Its longer, but helps with ctags/cscope navigation and we can go
directly to it via:
:ta threadpool_entry__open_p<TAB>
While 'ta: open_pipes' may bo to various places where this idiom is
used.
> +{
> + if (pipe(thread->pipes.from)) {
> + pr_err("threadpool: failed to create comm pipe 'from': %s\n",
> + strerror(errno));
> + return -ENOMEM;
> + }
> +
> + if (pipe(thread->pipes.to)) {
> + pr_err("threadpool: failed to create comm pipe 'to': %s\n",
> + strerror(errno));
> + close(thread->pipes.from[0]);
> + thread->pipes.from[0] = -1;
> + close(thread->pipes.from[1]);
> + thread->pipes.from[1] = -1;
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * close_pipes - close all communication pipes of @thread
> + */
> +static void close_pipes(struct thread_struct *thread)
> +{
> + if (thread->pipes.from[0] != -1) {
> + close(thread->pipes.from[0]);
> + thread->pipes.from[0] = -1;
> + }
> + if (thread->pipes.from[1] != -1) {
> + close(thread->pipes.from[1]);
> + thread->pipes.from[1] = -1;
> + }
> + if (thread->pipes.to[0] != -1) {
> + close(thread->pipes.to[0]);
> + thread->pipes.to[0] = -1;
> + }
> + if (thread->pipes.to[1] != -1) {
> + close(thread->pipes.to[1]);
> + thread->pipes.to[1] = -1;
> + }
> +}
> +
> +/**
> + * create_threadpool - create a fixed threadpool with @n_threads threads
> + */
> +struct threadpool_struct *create_threadpool(int n_threads)
Is this already something the kernel has and thus we should keep the
naming? I couldn't find it in the kernel, so please name it:
struct threadpool *threadpool__new(int nthreads)
> +{
> + int ret, t;
> + struct threadpool_struct *pool = malloc(sizeof(*pool));
> +
> + if (!pool) {
> + pr_err("threadpool: cannot allocate pool: %s\n",
> + strerror(errno));o
Humm, pr_err() at this level isn't appropriate, please make callers
complain.
> + return NULL;
> + }
> +
> + if (n_threads <= 0) {
> + pr_err("threadpool: invalid number of threads: %d\n",
> + n_threads);
pr_debug()
> + goto out_free_pool;
> + }
> +
> + pool->nr_threads = n_threads;
> + pool->current_task = NULL;
> +
> + pool->threads = malloc(n_threads * sizeof(*pool->threads));
> + if (!pool->threads) {
> + pr_err("threadpool: cannot allocate threads: %s\n",
> + strerror(errno));
> + goto out_free_pool;
> + }
> +
> + for (t = 0; t < n_threads; t++) {
> + pool->threads[t].idx = t;
> + pool->threads[t].tid = -1;
> + pool->threads[t].pool = pool;
> + init_pipes(&pool->threads[t]);
> + }
> +
> + for (t = 0; t < n_threads; t++) {
> + ret = open_pipes(&pool->threads[t]);
> + if (ret)
> + goto out_close_pipes;
> + }
> +
> + pool->status = THREADPOOL_STATUS__STOPPED;
> +
> + return pool;
> +
> +out_close_pipes:
> + for (t = 0; t < n_threads; t++)
> + close_pipes(&pool->threads[t]);
> +
> + free(pool->threads);
> +out_free_pool:
> + free(pool);
> + return NULL;
Here we can use ERR_PTR()/PTR_ERR() to let the caller know what was the
problem, i.e. we can ditch all the pr_err/pr_debug(), etc and instead
have a threadpool__strerror(struct threadpool *pool, int err) like we
have for 'struct evsel', please take a look at evsel__open_strerror().
> +}
> +
> +/**
> + * destroy_threadpool - free the @pool and all its resources
> + */
> +void destroy_threadpool(struct threadpool_struct *pool)
void threadpool__delete(struct threadpool *pool)
> +{
> + int t;
> +
> + if (!pool)
> + return;
> +
> + WARN_ON(pool->status != THREADPOOL_STATUS__STOPPED
> + && pool->status != THREADPOOL_STATUS__ERROR);
> +
> + for (t = 0; t < pool->nr_threads; t++)
> + close_pipes(&pool->threads[t]);
reset pool->threads[t] to -1
> +
> + free(pool->threads);
zfree
> + free(pool);
> +}
> +
> +/**
> + * threadpool_size - get number of threads in the threadpool
> + */
> +int threadpool_size(struct threadpool_struct *pool)
threadpool__size()
> +{
> + return pool->nr_threads;
> +}
> diff --git a/tools/perf/util/workqueue/threadpool.h b/tools/perf/util/workqueue/threadpool.h
> new file mode 100644
> index 0000000000000000..2b9388c768a0b588
> --- /dev/null
> +++ b/tools/perf/util/workqueue/threadpool.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __WORKQUEUE_THREADPOOL_H
> +#define __WORKQUEUE_THREADPOOL_H
> +
> +struct threadpool_struct;
> +struct task_struct;
> +
> +typedef void (*task_func_t)(int tidx, struct task_struct *task);
> +
> +struct task_struct {
> + task_func_t fn;
> +};
> +
> +extern struct threadpool_struct *create_threadpool(int n_threads);
> +extern void destroy_threadpool(struct threadpool_struct *pool);
> +
> +extern int threadpool_size(struct threadpool_struct *pool);
> +
> +#endif /* __WORKQUEUE_THREADPOOL_H */
> --
> 2.31.1
>
--
- Arnaldo
next prev parent reply other threads:[~2021-07-14 14:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 12:11 [RFC PATCH 00/10] perf: add workqueue library and use it in synthetic-events Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 01/10] perf workqueue: threadpool creation and destruction Riccardo Mancini
2021-07-14 14:16 ` Arnaldo Carvalho de Melo [this message]
2021-07-15 16:31 ` Riccardo Mancini
2021-07-15 20:48 ` Arnaldo Carvalho de Melo
2021-07-15 23:29 ` Namhyung Kim
2021-07-16 13:36 ` Riccardo Mancini
2021-07-19 19:39 ` Namhyung Kim
2021-07-13 12:11 ` [RFC PATCH 02/10] perf tests: add test for workqueue Riccardo Mancini
2021-07-14 15:10 ` Arnaldo Carvalho de Melo
2021-07-15 16:33 ` Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 03/10] perf workqueue: add threadpool start and stop functions Riccardo Mancini
2021-07-14 15:15 ` Arnaldo Carvalho de Melo
2021-07-15 16:42 ` Riccardo Mancini
2021-07-15 20:43 ` Arnaldo Carvalho de Melo
2021-07-15 23:48 ` Namhyung Kim
2021-07-16 13:53 ` Riccardo Mancini
2021-07-16 16:29 ` Arnaldo Carvalho de Melo
2021-07-13 12:11 ` [RFC PATCH 04/10] perf workqueue: add threadpool execute and wait functions Riccardo Mancini
2021-07-15 23:56 ` Namhyung Kim
2021-07-16 13:55 ` Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 05/10] perf workqueue: add sparse annotation header Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 06/10] perf workqueue: introduce workqueue struct Riccardo Mancini
2021-07-14 15:22 ` Arnaldo Carvalho de Melo
2021-07-15 16:49 ` Riccardo Mancini
2021-07-15 20:47 ` Arnaldo Carvalho de Melo
2021-07-13 12:11 ` [RFC PATCH 07/10] perf workqueue: implement worker thread and management Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 08/10] perf workqueue: add queue_work and flush_workqueue functions Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 09/10] perf workqueue: add utility to execute a for loop in parallel Riccardo Mancini
2021-07-13 12:11 ` [RFC PATCH 10/10] perf synthetic-events: use workqueue parallel_for Riccardo Mancini
2021-07-13 19:14 ` [RFC PATCH 00/10] perf: add workqueue library and use it in synthetic-events Arnaldo Carvalho de Melo
2021-07-19 21:13 ` Jiri Olsa
2021-07-22 16:15 ` Riccardo Mancini
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=YO7xpFg0F5Fv/7sI@kernel.org \
--to=acme@kernel.org \
--cc=alexey.v.bayduraev@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@redhat.com \
--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=peterz@infradead.org \
--cc=rickyman7@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.