From: Wang Jinchao <wangjinchao@xfusion.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>,
<linux-crypto@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<stone.xulei@xfusion.com>
Subject: Re: [RFC/REFACT] Refactoring and significantly reducing code complexity
Date: Sun, 8 Oct 2023 15:58:26 +0800 [thread overview]
Message-ID: <ZSJhIpRUPrT6Sag6@fedora> (raw)
In-Reply-To: <ZRZk6tC6j1FtW3uY@gauss3.secunet.de>
On Fri, Sep 29, 2023 at 07:47:22AM +0200, Steffen Klassert wrote:
> On Thu, Sep 28, 2023 at 04:53:38PM +0800, Wang Jinchao wrote:
> > This is a refactored version with the following main changes:
> >
> > - The parallel workqueue no longer uses the WQ_UNBOUND attribute
> > - Removal of CPU-related logic, sysfs-related interfaces
> > - removal of structures like padata_cpumask, and deletion of parallel_data
> > - Using completion to maintain sequencing
> > - no longer using lists
> > - removing structures like padata_list and padata_serial_queue
> > - Removal of padata_do_serial()
>
> This removes all the logic that is needed to ensure that
> the parallelized objects return in the same order as
> they were before the parallelization. This change makes
> padata unusable for networking.
Hello Steffen,
I have constructed a scenario where parallel() time cost
is forced to be reversed , and then ensured the order using serial().
The tests have passed on a 32-core machine.
Can you please explain if my refactored approach guarantees the serial ordering?
Here is the code:
padata_test.c
--------------
```c
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/padata.h>
struct request {
struct padata_priv padata;
int seq;
struct completion done;
};
#define TEST_ARRAY_SIZE 200
#define PARALLEL_BASE_TIME 10
static int serial_cnt;
static int shuffled;
struct request requests[TEST_ARRAY_SIZE];
void parallel(struct padata_priv *padata) {
struct request *req = container_of(padata, struct request, padata);
// The smaller the req->seq number, the longer the delay time
// creating a reverse order.
mdelay((TEST_ARRAY_SIZE - req->seq) * PARALLEL_BASE_TIME);
msleep((TEST_ARRAY_SIZE - req->seq) * PARALLEL_BASE_TIME);
}
void serial(struct padata_priv *padata) {
struct request *req = container_of(padata, struct request, padata);
if (req->seq != serial_cnt)
shuffled = 1;
serial_cnt++;
complete(&req->done);
}
struct padata_instance *pinst;
struct padata_shell *ps;
static int __init padata_test_init(void) {
serial_cnt = 0;
shuffled = 0;
pinst = padata_alloc("padata_test");
if (!pinst)
return -ENOMEM;
ps = padata_alloc_shell(pinst);
for (int i = 0; i < TEST_ARRAY_SIZE; i++) {
requests[i].padata.parallel = parallel;
requests[i].padata.serial = serial;
requests[i].seq = i;
init_completion(&requests[i].done);
}
for (int i = 0; i < TEST_ARRAY_SIZE; i++) {
padata_do_parallel(ps, &requests[i].padata);
}
// only wait for the last one
// if they were not done serially
// the serial_cnt will not be TEST_ARRAY_SIZE
// there was a shuffering
int last = TEST_ARRAY_SIZE - 1;
wait_for_completion(&requests[last].done);
if (serial_cnt != TEST_ARRAY_SIZE)
shuffled = 1;
printk(KERN_INFO "padata_test: shuffled %d serial_cnt %d\n", shuffled,
serial_cnt);
return 0;
}
static void __exit padata_test_exit(void) {
padata_free_shell(ps);
padata_free(pinst);
}
module_init(padata_test_init);
module_exit(padata_test_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("wangjinchao");
MODULE_DESCRIPTION("padata Test Module");
```
Makefile
---------
```makefile
obj-m += padata_test.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
```
run.sh
--------
```bash
make
dmesg -C
insmod padata_test.ko
rmmod padata_test
dmesg|grep serial_cnt
```
next prev parent reply other threads:[~2023-10-08 7:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 8:53 [RFC/REFACT] Refactoring and significantly reducing code complexity Wang Jinchao
2023-09-29 5:47 ` Steffen Klassert
2023-10-07 1:17 ` Wang Jinchao
2023-10-16 10:28 ` Steffen Klassert
2023-10-25 18:13 ` Daniel Jordan
2023-10-26 1:15 ` Wang Jinchao
2023-10-08 7:58 ` Wang Jinchao [this message]
2023-10-16 10:47 ` Steffen Klassert
2023-10-25 18:07 ` Daniel Jordan
2023-10-26 1:07 ` Wang Jinchao
2023-10-25 18:12 ` Daniel Jordan
2023-10-26 1:12 ` Wang Jinchao
2023-10-26 1:45 ` 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=ZSJhIpRUPrT6Sag6@fedora \
--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 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).