From: Wang Jinchao <wangjinchao@xfusion.com>
To: Steffen Klassert <steffen.klassert@secunet.com>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
<linux-crypto@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <stone.xulei@xfusion.com>
Subject: [RFC v2] padata: Simplify sysfs cpumask and sequencing logic
Date: Thu, 12 Oct 2023 10:06:40 +0800 [thread overview]
Message-ID: <202310121006-wangjinchao@xfusion.com> (raw)
Hi,
I've identified several potential optimizations for padata.
I'd appreciate it if you could take a look at my ideas to
see if they are feasible.
Utilizing the WQ_SYSFS from workqueue to support sysfs
======================================================
Padata relies on workqueue, and since workqueue has already implemented
support for cpumask through WQ_SYSFS, we can reuse this functionality
and avoid redundant implementation.
Link: https://docs.kernel.org/core-api/workqueue.html#affinity-scopes
Using completion to ensure the sequencing of the 'serial()'
===========================================================
In the current implementation, to ensure the sequencing of 'serial()',
we've used seq_nr, reorder_list, padata_serial_queue, reorder_work...
which has made the logic quite complex. These operations can be
simplified by using 'completion'. Specifically:
1. in padata_do_parallel()
1. init_completion(parallel_done) **before** queue_work
2. queue_work(serial_work)
2. in padata_parallel_worker
1. complete(parallel_done) **after** parallel(padata)
3. in padata_serial_worker
1. wait_for_completion(parallel_done) **before** serial(padata)
Here's a simplified code snippet:
```c
struct padata_priv {
struct completion parallel_done;
struct work_struct parallel_work;
struct work_struct serial_work;
void (*parallel)(struct padata_priv *padata);
void (*serial)(struct padata_priv *padata);
}
void padata_do_parallel(struct padata_priv *padata)
{
...
init_completion(&padata->parallel_done);
queue_work(pinst->serial_wq, &padata->serial_work);
queue_work(pinst->parallel_wq, &padata->parallel_work);
...
}
static void padata_parallel_worker(struct work_struct *parallel_work)
{
struct padata_priv *padata =
container_of(parallel_work, struct padata_priv, parallel_work);
padata->parallel(padata);
// notify serial_worker to do serial()
complete(&padata->parallel_done);
}
static void padata_serial_worker(struct work_struct *serial_work)
{
struct padata_priv *padata =
container_of(serial_work, struct padata_priv, serial_work);
wait_for_completion(&padata->parallel_done);
padata->serial(padata);
}
```
next reply other threads:[~2023-10-12 2:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 2:06 Wang Jinchao [this message]
2023-10-25 18:17 ` [RFC v2] padata: Simplify sysfs cpumask and sequencing logic Daniel Jordan
2023-10-26 1:26 ` Wang Jinchao
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=202310121006-wangjinchao@xfusion.com \
--to=wangjinchao@xfusion.com \
--cc=daniel.m.jordan@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=stone.xulei@xfusion.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.