* Re: [PATCH net-next v4 00/15][pull request] Introduce iXD driver
From: Tony Nguyen @ 2026-07-15 16:32 UTC (permalink / raw)
To: Larysa Zaremba
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
przemyslaw.kitszel, aleksander.lobakin, sridhar.samudrala,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc
In-Reply-To: <alUuiqh_VkGhQp7T@soc-5CG4396X81.clients.intel.com>
On 7/13/2026 11:29 AM, Larysa Zaremba wrote:
> I have addressed Sashiko's feedback for each patch.
>
> Those are the only 2 important changes that came out of that.
> Please, notice that the first one is not a functional regression, but a memory
> usage issue and I tested the change.
...
> Other changes are of much lesser importance. Look at particular patches for
> details on nice-to-haves and false positives.
I'll be submitting a v5 with these changes squashed in.
Thanks,
Tony
pw-bot: changes-requested
^ permalink raw reply
* Re: [linux-next:master] [crypto] 2f204fe718: stress-ng.af-alg.ops_per_sec 113.7% improvement
From: Eric Biggers @ 2026-07-15 16:27 UTC (permalink / raw)
To: kernel test robot; +Cc: oe-lkp, lkp, Herbert Xu, linux-doc, linux-crypto
In-Reply-To: <202607152204.a0a3bf98-lkp@intel.com>
On Wed, Jul 15, 2026 at 11:00:46PM +0800, kernel test robot wrote:
>
>
> Hello,
>
>
> we don't have enough knowledge to deeply analyze the impact of this commit
> to stress-ng.af-alg performance tests.
>
> along with the major kpi improvement:
>
> 7756377 +113.7% 16578454 stress-ng.af-alg.ops_per_sec
>
> we also noticed lots of misc tests seem have changes, e.g.
>
> 697423 -9.5% 630908 ± 2% stress-ng.af-alg.aes_cipher_ops/sec
> 245103 -100.0% 0.00 stress-ng.af-alg.blowfish_cipher_ops/sec
> 369646 -100.0% 0.00 stress-ng.af-alg.camellia_cipher_ops/sec
> 162192 -100.0% 0.00 stress-ng.af-alg.cast5_cipher_ops/sec
> 115113 -100.0% 0.00 stress-ng.af-alg.cast6_cipher_ops/sec
>
> we don't know if these are expected behavior upon 2f204fe718.
> so this report is just FYI what we observed in our tests.
>
>
>
> kernel test robot noticed a 113.7% improvement of stress-ng.af-alg.ops_per_sec on:
>
>
> commit: 2f204fe718f5bf519013cc2536ad7bb2cbb51661 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
That commit makes AF_ALG block access to some algorithms by default,
overridable by a sysctl. Apparently these performance tests
misinterpret that as a change in performance.
It actually doesn't make much sense to do performance testing on AF_ALG
at all anymore, given that AF_ALG is deprecated. A limited form of
AF_ALG is being left in place just for backwards compatibility with a
few programs. None of those programs use it in a performance-critical
way, as far as I know.
To the extent that it's still done at all, it shouldn't test random
algorithms like "ecb(cast5)" that are obsolete and unused.
- Eric
^ permalink raw reply
* Re: [PATCH v5 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Mathieu Poirier @ 2026-07-15 16:24 UTC (permalink / raw)
To: Tanmay Shah
Cc: andersson, corbet, skhan, linux-remoteproc, linux-doc,
linux-kernel
In-Reply-To: <20260710192831.3440427-4-tanmay.shah@amd.com>
On Fri, Jul 10, 2026 at 12:28:29PM -0700, Tanmay Shah wrote:
> 512 bytes isn't always suitable for all case, let firmware
> maker decide the best value from resource table.
> enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> Changes in v5:
>
> - fix documentation about alignment of the buffer size
> - change version field from u16 to u8
> - remove buffer alignment check
> - Separate buffer alignment vs MTU of a single buffer
> - Use buffer alignment only to get next buffer address at alignment
> boundary
>
> Changes in v4:
>
> - Introduce new patch to modify rpmsg.rst documentation
> - check version is always 1.
> - check size field is same as size of struct virtio_rpmsg_config
> - introduce alignment field
> - check alignment field is power of 2
> - check tx and rx buf size is aligned with alignment passed in the
> structure
>
> Changes in v3:
>
> - change version field from u16 to u8
> - introduce size field in the rpmsg_virtio_config structure
> - check version field is set to any non-zero value.
> - check size field is not 0.
> - Remove field for private config, as not needed for now.
> - add documentation of rpmsg_virtio_config structure
>
> drivers/rpmsg/virtio_rpmsg_bus.c | 130 ++++++++++++++++++++++++-----
> include/linux/rpmsg/virtio_rpmsg.h | 48 +++++++++++
> 2 files changed, 159 insertions(+), 19 deletions(-)
> create mode 100644 include/linux/rpmsg/virtio_rpmsg.h
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> index c84b6cec9caf..5e5473f4adeb 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -15,11 +15,13 @@
> #include <linux/idr.h>
> #include <linux/jiffies.h>
> #include <linux/kernel.h>
> +#include <linux/log2.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> #include <linux/rpmsg.h>
> #include <linux/rpmsg/byteorder.h>
> #include <linux/rpmsg/ns.h>
> +#include <linux/rpmsg/virtio_rpmsg.h>
> #include <linux/scatterlist.h>
> #include <linux/slab.h>
> #include <linux/sched.h>
> @@ -39,7 +41,10 @@
> * @tx_bufs: kernel address of tx buffers
> * @num_rx_buf: total number of rx buffers
> * @num_tx_buf: total number of tx buffers
> - * @buf_size: size of one rx or tx buffer
> + * @rx_buf_size: size of one rx buffer
> + * @tx_buf_size: size of one tx buffer
> + * @rx_buf_size_aligned: aligned size of one rx buffer
> + * @tx_buf_size_aligned: aligned size of one tx buffer
> * @last_tx_buf: index of last tx buffer used
> * @bufs_dma: dma base addr of the buffers
> * @tx_lock: protects svq and tx_bufs, to allow concurrent senders.
> @@ -59,7 +64,10 @@ struct virtproc_info {
> void *rx_bufs, *tx_bufs;
> unsigned int num_rx_buf;
> unsigned int num_tx_buf;
> - unsigned int buf_size;
> + unsigned int rx_buf_size;
> + unsigned int tx_buf_size;
> + unsigned int rx_buf_size_aligned;
> + unsigned int tx_buf_size_aligned;
> int last_tx_buf;
> dma_addr_t bufs_dma;
> struct mutex tx_lock;
> @@ -68,9 +76,6 @@ struct virtproc_info {
> wait_queue_head_t sendq;
> };
>
> -/* The feature bitmap for virtio rpmsg */
> -#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
> -
> /**
> * struct rpmsg_hdr - common header for all rpmsg messages
> * @src: source address
> @@ -128,7 +133,7 @@ struct virtio_rpmsg_channel {
> * processor.
> */
> #define MAX_RPMSG_NUM_BUFS (256)
> -#define MAX_RPMSG_BUF_SIZE (512)
> +#define DEFAULT_RPMSG_BUF_SIZE (512)
>
> /*
> * Local addresses are dynamically allocated on-demand.
> @@ -443,7 +448,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
>
> /* either pick the next unused tx buffer */
> if (vrp->last_tx_buf < vrp->num_tx_buf)
> - ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
> + ret = vrp->tx_bufs + vrp->tx_buf_size_aligned * vrp->last_tx_buf++;
> /* or recycle a used one */
> else
> ret = virtqueue_get_buf(vrp->svq, &len);
> @@ -513,7 +518,7 @@ static int rpmsg_send_offchannel_raw(struct rpmsg_device *rpdev,
> * messaging), or to improve the buffer allocator, to support
> * variable-length buffer sizes.
> */
> - if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) {
> + if (len > vrp->tx_buf_size - sizeof(struct rpmsg_hdr)) {
> dev_err(dev, "message is too big (%d)\n", len);
> return -EMSGSIZE;
> }
> @@ -646,7 +651,7 @@ static ssize_t virtio_rpmsg_get_mtu(struct rpmsg_endpoint *ept)
> struct rpmsg_device *rpdev = ept->rpdev;
> struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>
> - return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
> + return vch->vrp->tx_buf_size - sizeof(struct rpmsg_hdr);
> }
>
> static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> @@ -672,7 +677,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> * We currently use fixed-sized buffers, so trivially sanitize
> * the reported payload length.
> */
> - if (len > vrp->buf_size ||
> + if (len > vrp->rx_buf_size ||
> msg_len > (len - sizeof(struct rpmsg_hdr))) {
> dev_warn(dev, "inbound msg too big: (%d, %d)\n", len, msg_len);
> return -EINVAL;
> @@ -705,7 +710,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> dev_warn_ratelimited(dev, "msg received with no recipient\n");
>
> /* publish the real size of the buffer */
> - rpmsg_sg_init(&sg, msg, vrp->buf_size);
> + rpmsg_sg_init(&sg, msg, vrp->rx_buf_size);
>
> /* add the buffer back to the remote processor's virtqueue */
> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL);
> @@ -819,10 +824,13 @@ static int rpmsg_probe(struct virtio_device *vdev)
> struct virtproc_info *vrp;
> struct virtio_rpmsg_channel *vch = NULL;
> struct rpmsg_device *rpdev_ns, *rpdev_ctrl;
> + u16 rpmsg_buf_align = 0;
> void *bufs_va;
> int err = 0, i;
> size_t total_buf_space;
> bool notify;
> + u8 version;
> + u16 size;
>
> vrp = kzalloc_obj(*vrp);
> if (!vrp)
> @@ -854,9 +862,87 @@ static int rpmsg_probe(struct virtio_device *vdev)
> else
> vrp->num_tx_buf = MAX_RPMSG_NUM_BUFS;
>
> - vrp->buf_size = MAX_RPMSG_BUF_SIZE;
> + /*
> + * If VIRTIO_RPMSG_F_BUFSZ feature is supported, then configure buf
> + * size from virtio device config space from the resource table.
> + * If the feature is not supported, then assign default buf size.
> + */
> + if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_BUFSZ)) {
> + virtio_cread(vdev, struct virtio_rpmsg_config,
> + version, &version);
> +
> + /* for now we support only v1 */
> + if (version != RPMSG_VDEV_CONFIG_V1) {
> + dev_err(&vdev->dev,
> + "unsupported vdev config version %u\n", version);
> + err = -EINVAL;
> + goto vqs_del;
> + }
> +
> + /* size of the config space must match */
> + virtio_cread(vdev, struct virtio_rpmsg_config,
> + size, &size);
> + if (size != sizeof(struct virtio_rpmsg_config)) {
> + dev_err(&vdev->dev, "invalid size of vdev config %u\n",
> + size);
> + err = -EINVAL;
> + goto vqs_del;
> + }
>
> - total_buf_space = (vrp->num_rx_buf + vrp->num_tx_buf) * vrp->buf_size;
> + /*
> + * Optional alignment applied to each buffer size and to the TX
> + * buffer base address (e.g. to align buffers on a cache line).
> + * It must be a power of two; zero means no extra alignment.
> + */
> + virtio_cread(vdev, struct virtio_rpmsg_config,
> + rpmsg_buf_align, &rpmsg_buf_align);
> + if (rpmsg_buf_align && !is_power_of_2(rpmsg_buf_align)) {
> + dev_err(&vdev->dev,
> + "bad vdev config: rpmsg_buf_align %u is not a power of 2\n",
> + rpmsg_buf_align);
> + err = -EINVAL;
> + goto vqs_del;
> + }
> +
> + /* note: tx and rx are defined from remote view */
> + virtio_cread(vdev, struct virtio_rpmsg_config,
> + txbuf_size, &vrp->rx_buf_size);
> + virtio_cread(vdev, struct virtio_rpmsg_config,
> + rxbuf_size, &vrp->tx_buf_size);
> +
> + /* The buffers must hold at least the rpmsg header */
> + if (vrp->rx_buf_size < sizeof(struct rpmsg_hdr) ||
> + vrp->tx_buf_size < sizeof(struct rpmsg_hdr)) {
> + dev_err(&vdev->dev,
> + "bad vdev config: rx buf sz = %u, tx buf sz = %u\n",
> + vrp->rx_buf_size, vrp->tx_buf_size);
> + err = -EINVAL;
> + goto vqs_del;
> + }
> +
> + if (rpmsg_buf_align) {
> + vrp->rx_buf_size_aligned = ALIGN(vrp->rx_buf_size,
> + rpmsg_buf_align);
> + vrp->tx_buf_size_aligned = ALIGN(vrp->tx_buf_size,
> + rpmsg_buf_align);
> + } else {
> + vrp->rx_buf_size_aligned = vrp->rx_buf_size;
> + vrp->tx_buf_size_aligned = vrp->tx_buf_size;
> + }
> +
> + dev_dbg(&vdev->dev,
> + "vdev config: ver=%u, align=0x%x, rx sz = 0x%x, tx sz = 0x%x\n",
> + version, rpmsg_buf_align, vrp->rx_buf_size,
> + vrp->tx_buf_size);
> + } else {
> + vrp->rx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
> + vrp->tx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
> + vrp->rx_buf_size_aligned = vrp->rx_buf_size;
> + vrp->tx_buf_size_aligned = vrp->tx_buf_size;
> + }
> +
> + total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size_aligned) +
> + (vrp->num_tx_buf * vrp->tx_buf_size_aligned);
>
> /* allocate coherent memory for the buffers */
> bufs_va = dma_alloc_coherent(vdev->dev.parent,
> @@ -873,15 +959,20 @@ static int rpmsg_probe(struct virtio_device *vdev)
> /* first part of the buffers is dedicated for RX */
> vrp->rx_bufs = bufs_va;
>
> - /* and second part is dedicated for TX */
> - vrp->tx_bufs = bufs_va + vrp->num_rx_buf * vrp->buf_size;
> + /*
> + * Here buf_va is aligned to a page. Also rx buf size is aligned with
> + * cache line alignment provided by the firmware, so tx buf's start
> + * address is guranteed to be aligned with the alignment provided by
> + * the firmware.
> + */
> + vrp->tx_bufs = bufs_va + (vrp->num_rx_buf * vrp->rx_buf_size_aligned);
>
> /* set up the receive buffers */
> for (i = 0; i < vrp->num_rx_buf; i++) {
> struct scatterlist sg;
> - void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
> + void *cpu_addr = vrp->rx_bufs + i * vrp->rx_buf_size_aligned;
>
> - rpmsg_sg_init(&sg, cpu_addr, vrp->buf_size);
> + rpmsg_sg_init(&sg, cpu_addr, vrp->rx_buf_size);
>
> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, cpu_addr,
> GFP_KERNEL);
> @@ -964,8 +1055,8 @@ static int rpmsg_remove_device(struct device *dev, void *data)
> static void rpmsg_remove(struct virtio_device *vdev)
> {
> struct virtproc_info *vrp = vdev->priv;
> - unsigned int num_bufs = vrp->num_rx_buf + vrp->num_tx_buf;
> - size_t total_buf_space = num_bufs * vrp->buf_size;
> + size_t total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size_aligned) +
> + (vrp->num_tx_buf * vrp->tx_buf_size_aligned);
> int ret;
>
> virtio_reset_device(vdev);
> @@ -991,6 +1082,7 @@ static struct virtio_device_id id_table[] = {
>
> static unsigned int features[] = {
> VIRTIO_RPMSG_F_NS,
> + VIRTIO_RPMSG_F_BUFSZ,
> };
>
> static struct virtio_driver virtio_ipc_driver = {
> diff --git a/include/linux/rpmsg/virtio_rpmsg.h b/include/linux/rpmsg/virtio_rpmsg.h
> new file mode 100644
> index 000000000000..735a947d5582
> --- /dev/null
> +++ b/include/linux/rpmsg/virtio_rpmsg.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Pinecone Inc. 2019
> + * Copyright (C) Xiang Xiao <xiaoxiang@pinecone.net>
> + * Copyright (C) Advanced Micro Devices, Inc. 2026
> + */
> +
> +#ifndef _LINUX_VIRTIO_RPMSG_H
> +#define _LINUX_VIRTIO_RPMSG_H
> +
> +#include <linux/types.h>
> +#include <linux/virtio_types.h>
> +
> +/* The feature bitmap for virtio rpmsg */
> +#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
> +#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config space */
> +
> +/* Version of struct virtio_rpmsg_config understood by this driver */
> +#define RPMSG_VDEV_CONFIG_V1 1
> +
> +/**
> + * struct virtio_rpmsg_config - config space for rpmsg virtio device
> + *
> + * @version: version of this structure, currently %RPMSG_VDEV_CONFIG_V1.
> + * @size: size of this structure in bytes.
> + * @rpmsg_buf_align: alignment in bytes for each buffer. Must be a power of
> + * two. If 0 then no alignment will be done. This alignment
> + * will not decide actual size of the buffer but will be
> + * used to decided the start address of the buffer. The
> + * actual size of the buffer can be different than the
> + * aligned size of the buffer.
Is there really a need to have a buffer size different from its alignment? It's
not like the (small) delta between the buffer size and its alignment will be
used for something else. I'm fine with a buffer alignment requirement but in
those cases, the firmware should set the size of the buffer in accordance with
its alignment requirement. Otherwise, the complexity needed to manage the
discrpancy between the two yields a driver that is hard to maintain and prone to
bugs.
> + * @txbuf_size: Tx buf size from remote's view. For Linux this is rx buf size.
> + * @rxbuf_size: Rx buf size from remote's view. For Linux this is tx buf size.
> + *
> + * This is the configuration structure shared by the device and the driver,
> + * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are laid out so
> + * the structure is naturally 32-bit aligned.
> + */
> +struct virtio_rpmsg_config {
> + u8 version;
> + __virtio16 size;
> + __virtio16 rpmsg_buf_align;
> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
> + __virtio32 txbuf_size;
> + __virtio32 rxbuf_size;
> +} __packed;
> +
> +#endif /* _LINUX_VIRTIO_RPMSG_H */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg()
From: Yosry Ahmed @ 2026-07-15 16:14 UTC (permalink / raw)
To: Hao Jia
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <2bc8e4f6-46a0-5b74-6eaa-59e7aef9227e@gmail.com>
> >> Test Setup:
> >> Total memory: 32 GB.
> >> zswap settings: max_pool_percent=1, accept_threshold_percent=50,
> >> shrinker_enabled=N.
> >> Allocate 512MB of anonymous pages and fill them with random data (to avoid
> >> compression), then use cgroup memory.reclaim to force a large amount of
> >> anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous
> >> page where the first 4 bytes are random numbers and the rest are zeros, and
> >> then trigger a reclamation of this 4K anonymous page through cgroup
> >> memory.reclaim. When the pool threshold is reached, shrink_memcg() will
> >> be triggered.
> >>
> >> The test data after running for 120s is as follows:
> >> Baseline Patched
> >> shrink_worker wakeups 5363 85
> >> shrink_memcg calls 11,345,012 188,264
> >> written_back 40214 40275
> >>
> >> Conclusion:
> >> Under the same workload and run duration, the patched kernel shows a
> >> significant reduction in both shrink_worker wakeups and shrink_memcg calls.
> >
> > Please also include data from the case where zswap store failures are
> > observed and pages go to disk, and compare before and after this
> > patch. I think that part is also really important.
>
> I retested and added some collected information. Perhaps
> `pool_limit_hit` and `pswpout` can explain that batch shrinking of zswap
> can reduce the number of pages that fail to be stored due to the pool
> limit, allowing zswap to skip zswap and go directly to disk.
Oh I meant the other test case with high memory pressure where we saw
a lot more writeback with this patch. Do you have similar data from
that test case?
>
> Baseline Patched
> shrink_worker wakeups 5,363 85
> shrink_memcg calls 11,373,201 180,928
> written_back pages 40,212 40,236
> zswap_store calls 161,190 168,741
> store succeeded (ret=1) 102,743 127,644
> store rejected (ret=0) 58,447 41,097
> store reject rate ~36% ~24%
> pool_limit_hit delta 55,826 14,062
> pswpout 98,659 81,333
> pswpin 2 1
>
>
> Thanks,
> Hao
^ permalink raw reply
* Re: [PATCH 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled
From: Yosry Ahmed @ 2026-07-15 16:13 UTC (permalink / raw)
To: Hao Jia
Cc: Andrew Morton, nphamcs, tj, hannes, shakeel.butt, mhocko, mkoutny,
chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia, stable
In-Reply-To: <7a1fe347-7ca6-4768-9308-420bf1251f54@gmail.com>
On Wed, Jul 15, 2026 at 5:31 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>
>
>
> On 2026/7/15 10:31, Andrew Morton wrote:
> > On Tue, 14 Jul 2026 09:52:59 -0700 Yosry Ahmed <yosry@kernel.org> wrote:
> >
> >>> When memory cgroup is disabled, mem_cgroup_iter() always returns NULL.
> >>> Therefore, the global shrinker shrink_worker() always takes the !memcg
> >>> branch. After MAX_RECLAIM_RETRIES empty walks, the worker simply gives up,
> >>> so it fails to write back anything.
> >>>
> >>> Therefore, when memory cgroup is disabled, fall through with the !memcg
> >>> branch and shrink the root memcg directly.
> >>>
> >>> With memcg disabled, shrink_memcg() only returns -ENOENT when the root
> >>> LRU is empty, which means the total pages are already below thr. The
> >>> loop then safely bails out via the zswap_total_pages() <= thr check.
> >>> For any other return value from shrink_memcg(), the loop is guaranteed
> >>> to terminate, either after MAX_RECLAIM_RETRIES failures or once the
> >>> threshold is met.
> >>>
> >>> Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware")
> >>> Cc: stable@vger.kernel.org
> >>> Suggested-by: Nhat Pham <nphamcs@gmail.com>
> >>> Acked-by: Nhat Pham <nphamcs@gmail.com>
> >>> Acked-by: Yosry Ahmed <yosry@kernel.org>
> >>> Reported-by: Yosry Ahmed <yosry@kernel.org>
> >>> Closes: https://lore.kernel.org/all/CAO9r8zPVzMKFbCixxD-qgtRrkFxWVrHiZZeLc=eyTPKPVQgX4g@mail.gmail.com
> >>> Signed-off-by: Hao Jia <jiahao1@lixiang.com>
> >>
> >> Patch 2 doesn't really depend on this one, right?
> >>
> >> If that's the case I think this can (and should be) picked up
> >> separately as a hotfix. Andrew, WDYT?
> >
> > Please update the changelog to clearly describe the userspace-visible
> > effects of the bug, thanks.
>
> I am not entirely sure if my understanding is correct here, but maybe I
> should add something like this to the commit message?
>
> When cgroup_disable=memory is used (or with CONFIG_MEMCG=n), the global
> shrinker fails to write back any pages. Consequently, the zswap pool
> fills up to its limit and rejects further storage, preventing memory
> pressure from being offloaded to the backing swap device.
I think you can simply write that zswap writeback when the limit is
hit is broken when memcg is disabled.
>
> > Also, AI review has flagged several possible issues, all appear to be
> > serious:
> > https://sashiko.dev/#/patchset/20260714081510.16895-1-jiahao.kernel@gmail.com
>
> For AI review comments on this patch:
> I suspect this scenario might only exist in theory. For zswap LRU to be
> empty while zswap_total_pages() > thr holds true, it would require a
> prolonged state where there are always more than thr zswap entries on
> the zswap LRU whenever zswap_total_pages() > thr is evaluated, yet the
> zswap LRU happens to be empty during shrink_memcg(root_memcg).
>
> If we want to fix this, perhaps we could do something like this?
>
> Yosry, Nhat, what are your thoughts on this?
Do we need to do this? The last paragraph in your changelog explains
why this can't happen because zswap_total_pages() should be 0 in this
case. Did I miss something?
^ permalink raw reply
* Re: [PATCH v21 06/14] dmaengine: qcom: bam_dma: add support for BAM locking
From: Stephan Gerhold @ 2026-07-15 16:06 UTC (permalink / raw)
To: Vinod Koul
Cc: Jonathan Corbet, Thara Gopinath, Herbert Xu, David S. Miller,
Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Bjorn Andersson, Peter Ujfalusi,
Michal Simek, Frank Li, Andy Gross, Neil Armstrong, dmaengine,
linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <alepDnRJmRLbFGRQ@vaman>
On Wed, Jul 15, 2026 at 09:06:46PM +0530, Vinod Koul wrote:
> On 15-07-26, 14:43, Bartosz Golaszewski wrote:
> > On Tue, 14 Jul 2026 11:49:14 +0200, Stephan Gerhold
> > <stephan.gerhold@linaro.org> said:
> > > On Mon, Jul 13, 2026 at 03:01:07PM +0200, Bartosz Golaszewski wrote:
> > >> Add support for BAM pipe locking. To that end: when starting DMA on an RX
> > >> channel - prepend the existing queue of issued descriptors with an
> > >> additional "dummy" command descriptor with the LOCK bit set. Once the
> > >> transaction is done (no more issued descriptors), issue one more dummy
> > >> descriptor with the UNLOCK bit.
> > >>
> > >> We *must* wait until the transaction is signalled as done because we
> > >> must not perform any writes into config registers while the engine is
> > >> busy.
> > >>
> > >> The dummy writes must be issued into a scratchpad register of the client
> > >> so provide a mechanism to communicate the right address via descriptor
> > >> metadata.
> > >>
> > >> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> > >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > [...]
> > >> ---
> > >> drivers/dma/qcom/bam_dma.c | 191 +++++++++++++++++++++++++++++++++++++--
> > >> include/linux/dma/qcom_bam_dma.h | 14 +++
> > >> 2 files changed, 198 insertions(+), 7 deletions(-)
> > >>
> > >> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> > >> index f3e713a5259c2c7c24cfdcec094814eb1202971a..f08549ee3872eece85884606d6ee9e540ee688ca 100644
> > >> --- a/drivers/dma/qcom/bam_dma.c
> > >> +++ b/drivers/dma/qcom/bam_dma.c
> > >> [...]
> > >> @@ -686,6 +702,35 @@ static int bam_slave_config(struct dma_chan *chan,
> > >> return 0;
> > >> }
> > >>
> > >> +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> > >> +{
> > >> + struct bam_chan *bchan = to_bam_chan(desc->chan);
> > >> + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> > >> + struct bam_desc_metadata *metadata = data;
> > >> +
> > >> + if (!data)
> > >
> > > Doesn't really matter much, but since the parameter exists you might as
> > > well add
> > >
> > > && len == sizeof(*metadata)
> > >
> > > here to be sure.
> > >
> >
> > Ok.
> >
> > >> + return -EINVAL;
> > >> +
> > >> + if (!bdata->pipe_lock_supported)
> > >> + /*
> > >> + * The client wants to use locking but this BAM version doesn't
> > >> + * support it. Don't return an error here as this will stop the
> > >> + * client from using DMA at all for no reason.
> > >> + */
> > >> + return 0;
> > >> +
> > >> + guard(spinlock_irqsave)(&bchan->vc.lock);
> > >> +
> > >> + bchan->scratchpad_addr = metadata->scratchpad_addr;
> > >> + bchan->direction = metadata->direction;
> > >> +
> > >> + return 0;
> > >> +}
> > >> +
> > >> +static const struct dma_descriptor_metadata_ops bam_metadata_ops = {
> > >> + .attach = bam_metadata_attach,
> > >> +};
> > >
> > > I'm not sure if we have discussed this before, but could we avoid
> > > re-programming the scratchpad_addr all the time by placing it into
> > > struct dma_slave_config -> peripheral_config? It still feels awkward to
> > > me to place a global constant configuration value into per-descriptor
> > > metadata.
>
> The concept is that a dmaengine can handle multiple peripherals, so the
> peripheral is always per desciptor
>
> > Yes, this was discussed several versions ago. I went with using
> > dmaengine_slave_config() until v11. I think Vinod or Dmitry requested we change
> > it to the metadata.
>
> metadata seems better fit for this.
>
Modelling this as descriptor metadata is really misleading. You call
dmaengine_desc_attach_metadata() on a specific descriptor, but then the
bam_metadata_attach() above just writes it globally into
desc->chan (struct dma_chan) -> to_bam_chan() (struct bam_chan)
-> bchan->scratchpad_addr
The descriptor that you pass in is completely unused. If you call this
on a different descriptor later with a different value, it will just
change the global configuration for the previous descriptor as well (if
they are submitted together). It will always be like this, since it's
the entire channel (and descriptor sequence) that is locked and not an
individual descriptor.
dmaengine_slave_config() operates directly on the struct dma_chan, so it
is IMO the right place to add this. That makes it clear that this
configures something for the entire channel.
I don't think that breaks support for multiple peripherals connected to
a single BAM (dmaengine). A BAM pipe (channel) should always belong to a
single peripheral. And even if it belongs to multiple peripherals, we
still need a single "scratchpad_addr" to use for the lock/unlock
sequence.
I would avoid using struct dma_slave_config->dst_addr (like in v11) [1]
though, since it's more a "address to dummy register" now than the
actual dst_addr of the peripheral. That's why I suggested
struct dma_slave_config->peripheral_config.
Thanks,
Stephan
[1]: https://lore.kernel.org/linux-arm-msm/20260302-qcom-qce-cmd-descr-v11-7-4bf1f5db4802@oss.qualcomm.com/
^ permalink raw reply
* Re: [PATCH v2 0/4] mm/hmm: Clarify notifier retry state and scope HMM timeouts
From: Lorenzo Stoakes (ARM) @ 2026-07-15 16:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Stanislav Kinsburskii, David Hildenbrand (Arm), airlied, akhilesh,
akpm, corbet, dakr, kees, leon, liam, lizhi.hou, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
dri-devel, linux-mm, linux-doc, linux-kernel, linux-kselftest,
linux-rdma
In-Reply-To: <20260715150210.GA3846105@ziepe.ca>
On Wed, Jul 15, 2026 at 12:02:10PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote:
>
> > > > Stanislav Kinsburskii (4):
> > > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
> > > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults
> > > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population
> > > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults
> > >
> > > Why a fixup series instead of properly resending the full thing?
> > >
> >
> > The goal was to get a Sashiko review, and v8 has already been applied to
> > both `mm-new` and `linux-next`.
>
> I think if you send the whole thing with a base-commit tag that
> specifies a real base commit in linux-next sashiko should work
>
> Jason
Oh so just use b4 then :)
^ permalink raw reply
* Re: [PATCH v2 0/4] mm/hmm: Clarify notifier retry state and scope HMM timeouts
From: Lorenzo Stoakes (ARM) @ 2026-07-15 16:02 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: David Hildenbrand (Arm), airlied, akhilesh, akpm, corbet, dakr,
jgg, kees, leon, liam, lizhi.hou, lyude, maarten.lankhorst,
mamin506, mhocko, mripard, nouveau, ogabbay, oleg, rppt, shuah,
simona, skhan, surenb, tzimmermann, vbabka, dri-devel, linux-mm,
linux-doc, linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alecaJ1FUso39D9k@skinsburskii>
To avoid confusion: obviously please don't merge this series Andrew.
On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote:
> On Wed, Jul 15, 2026 at 02:41:43PM +0200, David Hildenbrand (Arm) wrote:
> > On 7/15/26 00:21, Stanislav Kinsburskii wrote:
> > > This small fixup series applies on top of:
> > >
> > > [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
> > >
> > > The first patch updates the HMM documentation example to make the
> > > mmu_interval_read_retry() state explicit: callers should use the notifier and
> > > notifier_seq stored in the same hmm_range that was passed to
> > > hmm_range_fault_unlocked_timeout().
> > >
> > > The remaining patches adjust nouveau, amdxdna, and drm_gpusvm users so the
> > > timeout passed to hmm_range_fault_unlocked_timeout() is treated as a relative
> > > HMM retry budget. These callers no longer keep an absolute deadline around
> > > their outer driver retry loops or pass a computed remaining time into HMM.
> > >
> > > This keeps the timeout scoped to HMM's internal mmu-notifier retry handling. If
> > > HMM succeeds and the driver later observes an invalidation through
> > > mmu_interval_read_retry(), the driver retries the operation with a fresh HMM
> > > retry budget.
> > >
> > > Changes in v2:
> > > - Kept the nouveau outer absolute timeout around the
> > > mmu_interval_read_retry() loop. hmm_range_fault_unlocked_timeout() only
> > > bounds HMM’s internal retries, while nouveau faults are handled from a GPU
> > > fault worker, so userspace fatal signals cannot break an endless stream of
> > > invalidations there.
> > > - Updated nouveau to use time_after_eq() before calling HMM, so the remaining
> > > timeout passed to hmm_range_fault_unlocked_timeout() is always positive and
> > > never 0, which would mean retry indefinitely.
> > > - Updated the nouveau fixup commit message to explain the worker-thread
> > > timeout issue and the time_after_eq() boundary behavior.
> > > - Fixed the amdxdna fixup commit message. It now describes
> > > aie2_populate_range() correctly instead of carrying stale nouveau prose,
> > > and notes that command submission still keeps its broader timeout while HMM
> > > gets a fresh relative retry budget.
> > >
> > >
> > > ---
> > >
> > > Stanislav Kinsburskii (4):
> > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
> > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults
> > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population
> > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults
> >
> > Why a fixup series instead of properly resending the full thing?
> >
>
> The goal was to get a Sashiko review, and v8 has already been applied to
> both `mm-new` and `linux-next`.
Please don't do this, this is completely impossible to track for review :)
mm review is currently very difficult based on volumes, it'll become impossible
to manage if people sound fragments of series.
Please just resend the whole thing at this point.
>
> You can find more details here:
>
> https://sashiko.dev/#/message/alaWmUEeIBeSkmO0%40skinsburskii
>
> Thanks, Stanislav
>
> > --
> > Cheers,
> >
> > David
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v5 0/3] x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch
From: Reinette Chatre @ 2026-07-15 16:02 UTC (permalink / raw)
To: Gavin Shan, Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <9892de2f-9e29-41ff-997b-a6a2e7c98585@redhat.com>
On 7/14/26 5:13 PM, Gavin Shan wrote:
> Looks good in my tests on NVidia's grace-hopper machine. No errors found
> from the kunit-tests and the MBW limiting works with more precise granularity.
> The code changes look good to me either.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
Thank you very much Gavin.
Reinette
^ permalink raw reply
* RE: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
From: Shenwei Wang (OSS) @ 2026-07-15 15:55 UTC (permalink / raw)
To: Mathieu Poirier, Shenwei Wang (OSS)
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn
In-Reply-To: <alemgbM2ktRLE9wT@p14s>
> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> Sent: Wednesday, July 15, 2026 10:26 AM
> To: Shenwei Wang (OSS) <shenwei.wang@oss.nxp.com>
> Cc: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> Andersson <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Shenwei Wang <shenwei.wang@nxp.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Arnaud
> POULIQUEN <arnaud.pouliquen@foss.st.com>; b-padhi@ti.com; Andrew Lunn
> <andrew@lunn.ch>
> Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg
> bus
>
> On Tue, Jul 14, 2026 at 06:43:30PM +0000, Shenwei Wang (OSS) wrote:
> >
> >
> > > -----Original Message-----
> > > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > > Sent: Tuesday, July 14, 2026 11:36 AM
> > > To: Shenwei Wang (OSS) <shenwei.wang@oss.nxp.com>
> > > Cc: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski
> > > <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
> > > <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor
> > > Dooley <conor+dt@kernel.org>; Bjorn Andersson
> > > <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>;
> > > linux- gpio@vger.kernel.org; linux-doc@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Shenwei
> > > Wang <shenwei.wang@nxp.com>; Peng Fan <peng.fan@nxp.com>;
> > > devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> > > imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> > > dl-linux-imx <linux-imx@nxp.com>; Arnaud POULIQUEN
> > > <arnaud.pouliquen@foss.st.com>; b-padhi@ti.com; Andrew Lunn
> > > <andrew@lunn.ch>
> > > Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio
> > > driver over rpmsg bus
> > >
> > > On Tue, Jul 14, 2026 at 02:29:12PM +0000, Shenwei Wang (OSS) wrote:
> > d
> > > > > > + - 3: Both edge trigger
> > > > > > + - 4: High level trigger
> > > > > > + - 8: Low level trigger
> > > > >
> > > > > I'm in agreement with cmd 3, 4, 5 and 6.
> > > > >
> > > >
> > > > How about cmd 2?
> > >
> > > Yes, I forgot cmd 2.
> > >
> > > >
> > > > > > +
> > > > > > +**Reply:**
> > > > > > +
> > > > > > +.. code-block:: none
> > > > > > +
> > > > > > + +------+--------+--------+
> > > > > > + | 0x00 | 0x01 | 0x02 |
> > > > > > + | 1 | status | 0 |
> > > > > > + +------+--------+--------+
> > > > > > +
> > > > > > +- **status**:
> > > > > > +
> > > > > > + - 0: Ok
> > > > > > + - 1: Error
> > > > > > +
> > > > > > +SET_WAKEUP (Cmd=16)
> > > > > > +~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > I already commented on messages that are not part of the
> > > > > virtio-gpio specification.
> > > > >
> > > >
> > > > I don't believe virtio-gpio needs a SET_WAKEUP command.
> > > >
> > > > In the RPMSG case, SET_WAKEUP is required because it performs an
> > > > operation on the remote processor, so the remote side must be
> > > > explicitly
> > > notified.
> > >
> > > What operations would that be?
> > >
> >
> > The operation is enabling the line as a wakeup source. In practice,
> > this involves configuring hardware-specific wakeup settings (e.g.,
> > register bits) on the remote processor, so the remote side must be explicitly
> notified through SET_WAKEUP.
> >
>
> As I said before, we are not enhancing the virtio-gpio specification. If the
> functionality is not part of the specification, it is not part of this protocol.
>
It's about the functionality, not the specification.
Without SET_WAKEUP, a virtio-GPIO line can still be used as a wakeup source, but
an RPMSG implementation cannot because the remote processor is never notified
to configure its wakeup settings.
So both implementations may follow the same virtio-gpio specification, but they do
not provide the same wakeup functionality.
Anyway, if you want to drop the function, the command can be removed.
Shenwei
> >
> > > >
> > > > For virtio-gpio, however, everything is handled locally. The other
> > > > side does not need to perform any action, so sending a SET_WAKEUP
> > > > command
> > > appears unnecessary.
> > >
> > > What is "everything"?
> > >
> >
> > I mean masking, unmasking, and marking the interrupt as a wakeup
> > source. All of these operations are handled on local processor.
>
> There may be enough capability in your remote processor to do all that, but we
> can't assume the same applies to all implementations. rpmsg-gpio is not about
> inventing a new protocol or delegating actions to the remote processor. It is
> about carrying virtio-gpio packets on top of RPMSG. It needs to operate
> _exactly_ the same way as virtio-gpio.
>
> >
> > Shenwei
> >
> > > >
> > > >
> > > > > > +
> > > > > > +**Request:**
> > > > > > +
> > > > > > +.. code-block:: none
> > > > > > +
> > > > > > + +------+------+------+------+------+------+------+------+
> > > > > > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > > > > > + | 1 | line | value |
> > > > > > + +------+------+------+------+------+------+------+------+
> > > > > > +
> > > > > > +- **value**: Wakeup enable.
> > > > > > +
> > > > > > + The remote system should always aim to stay in a
> > > > > > + power-efficient state by shutting down or clock-gating the
> > > > > > + GPIO blocks that aren't in use. Since the remoteproc driver
> > > > > > + is responsible for managing the power states of the remote
> > > > > > + firmware, the GPIO driver does not require to know the
> > > > > > + firmware's
> > > running states.
> > > > > > +
> > > > > > + When the wakeup bit is set, the remote firmware should
> > > > > > + configure the line as a wakeup source. The firmware should
> > > > > > + send the notification message to Linux after it is woken from the GPIO
> line.
> > > > > > +
> > > > > > + - 0: Disable wakeup from GPIO
> > > > > > + - 1: Enable wakeup from GPIO
> > > > > > +
> > > > > > +**Reply:**
> > > > > > +
> > > > > > +.. code-block:: none
> > > > > > +
> > > > > > + +------+--------+--------+
> > > > > > + | 0x00 | 0x01 | 0x02 |
> > > > > > + | 1 | status | 0 |
> > > > > > + +------+--------+--------+
> > > > > > +
> > > > > > +- **status**:
> > > > > > +
> > > > > > + - 0: Ok
> > > > > > + - 1: Error
> > > > > > +
> > > > > > +Notification Message
> > > > > > +--------------------
> > > > >
> > > > > "Interrupt Messages"
> > > > >
> > > > > > +
> > > > > > +Notifications are sent by the remote core and they have
> > > > > > +**Type=2 (GPIO_RPMSG_NOTIFY)**:
> > > > > > +
> > > > > > +When a GPIO line asserts an interrupt on the remote
> > > > > > +processor, the firmware should immediately mask the
> > > > > > +corresponding interrupt source and send a notification
> > > > > > +message to the Linux. Upon completion of the interrupt
> > > > > > +handling on the Linux side, the driver should issue a command
> > > > > > +**SET_IRQ_TYPE** to the firmware to
> > > unmask the interrupt.
> > > > > > +
> > > > > > +A Notification message can arrive between a SEND and its
> > > > > > +REPLY message, and the driver is expected to handle this scenario.
> > > > > > +
> > > > > > +.. code-block:: none
> > > > > > +
> > > > > > + +------+------+--------+
> > > > > > + | 0x00 | 0x01 | 0x02 |
> > > > > > + | 2 | line | trigger|
> > > > > > + +------+------+--------+
> > > > >
> > > > > 2 things here:
> > > > >
> > > > > 1) You did not include messages that mask and unmask interrupts
> > > > > at the driver side.
> > > >
> > > > Interrupt masking and unmasking are handled entirely on the local
> processor.
> > > >
> > > > When an interrupt occurs, the remote system masks the interrupt
> > > > and then sends a notification to Linux. After Linux processes the
> > > > notification, it sends a SET_IRQ_TYPE message back to the remote
> > > > system,
> > > which then unmasks the interrupt.
> > >
> > > This is the kind of information that should be part of this documentation.
> > >
> > > >
> > > > Thanks,
> > > > Shenwei
> > > >
> > > > >
> > > > > 2) We are carrying virtio-gpio messages on top of RPMSG and as
> > > > > such, this whole protocol should be about thar:
> > > > >
> > > > > +------+------+--------+--------
> > > > > | 0x00 | payload |
> > > > > | Q | |
> > > > > +------+------+--------+--------
> > > > >
> > > > > Q = 0 requestq
> > > > > Q = 1 eventq
> > > > >
> > > > > The "payload" part is simply the format of the messages as found
> > > > > in the virtio- gpio specification. From there, the only thing
> > > > > left to mention is which messages are not supported, i.e get line names.
> > > > >
> > > > > > +
> > > > > > +- **line**: The GPIO line (pin) index of the port.
> > > > > > +
> > > > > > +- **trigger**: Optional parameter to indicate the trigger event type.
> > > > >
> > > > > Not part of the spec - remove.
> > > > >
> > > > > Given the refactoring work that is still needed, I will not look
> > > > > at the implementation.
> > > > >
> > > > > Thanks,
> > > > > Mathieu
> > > > >
> > > > > > +
> > > > > > diff --git a/Documentation/driver-api/gpio/index.rst
> > > > > > b/Documentation/driver-api/gpio/index.rst
> > > > > > index bee58f709b9a..e5eb1f82f01f 100644
> > > > > > --- a/Documentation/driver-api/gpio/index.rst
> > > > > > +++ b/Documentation/driver-api/gpio/index.rst
> > > > > > @@ -16,6 +16,7 @@ Contents:
> > > > > > drivers-on-gpio
> > > > > > bt8xxgpio
> > > > > > pca953x
> > > > > > + gpio-rpmsg
> > > > > >
> > > > > > Core
> > > > > > ====
> > > > > > --
> > > > > > 2.43.0
> > > > > >
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 15:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <CANn89iLV9pyCKU4vyNMzW5FFv4=Xcq_pgvZaFhzJHAAbCK0h7w@mail.gmail.com>
On 2026/7/15 23:30, Eric Dumazet wrote:
> On Wed, Jul 15, 2026 at 5:26 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> On 2026/7/15 23:15, Eric Dumazet wrote:
>>> On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> [...]
>>
>>>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>>>> index 61045a8886e4..4f1027173e95 100644
>>>> --- a/net/ipv4/tcp_input.c
>>>> +++ b/net/ipv4/tcp_input.c
>>>> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
>>>> /* When we get a reset we do this. */
>>>> void tcp_reset(struct sock *sk, struct sk_buff *skb)
>>>> {
>>>> + const struct net *net = sock_net(sk);
>>>> int err;
>>>>
>>>> trace_tcp_receive_reset(sk);
>>>> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
>>>> err = ECONNREFUSED;
>>>> break;
>>>> case TCP_CLOSE_WAIT:
>>>> + /* RFC9293 3.10.7.4. Other States
>>>> + * Second, check the RST bit:
>>>> + * CLOSE-WAIT STATE
>>>> + *
>>>> + * If the RST bit is set, then any outstanding RECEIVEs and
>>>> + * SEND should receive "reset" responses. All segment queues
>>>> + * should be flushed. Users should also receive an unsolicited
>>>> + * general "connection reset" signal. Enter the CLOSED state,
>>>> + * delete the TCB, and return.
>>>> + *
>>>> + * If net.ipv4.tcp_purge_receive_queue is enabled,
>>>> + * sk_receive_queue will be flushed too.
>>>> + */
>>>> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
>>>> + struct tcp_sock *tp = tcp_sk(sk);
>>>> +
>>>> + skb_queue_purge(&sk->sk_receive_queue);
>>>> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
>>>> + WRITE_ONCE(tp->urg_data, 0);
>>>> + sk_set_peek_off(sk, -1);
>>>> + }
>>>> err = EPIPE;
>>>> break;
>>>> case TCP_CLOSE:
>>>> --
>>>> 2.55.0
>>>>
>>>
>>> My thoughts are:
>>>
>>> out_of_order_queue has been forgotten. skbs could be there and still
>>> 'block devmem'
>>>
>>> WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
>>> read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
>>> So the application will not know a RST was received :/
>>>
>>> I think that BSD and linux implementations have historically retained
>>> acknowledged,
>>> buffered receive data upon RST to allow applications to drain data
>>> already ACKed prior to the reset.
>>>
>>> Adding a narrow sysctl specifically for CLOSE_WAIT creates
>>> inconsistent behavior across TCP states.
>>
>>
>> Got it. I won't pursue this sysctl approach in the future. Thanks for
>> the review.
>
> My intention was not to kill your proposal, only to start a conversation...
Thanks for clarifying. I agree this approach needs more thought.
Thanks,
Leon
^ permalink raw reply
* [PATCH 1/1] CodingStyle: clarify variable naming rules
From: Alexey Dobriyan @ 2026-07-15 15:42 UTC (permalink / raw)
To: corbet, skhan; +Cc: adobriyan, linux-doc, linux-kernel
* sysctl stuff better have "sysctl" in its name to remind developers
to use READ_ONCE() and that their values can change at any time,
* variable holding physical time should append unit of time to the name,
to make life easier for developers and static checkers.
Jiffies aren't included because I'd be crucified for "_ji".
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
Documentation/process/coding-style.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index a8336582f60b..d97ed5be4eab 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -356,6 +356,11 @@ specification that mandates those terms. For new specifications
translate specification usage of the terminology to the kernel coding
standard where possible.
+Variable holding sysctl value should have ``sysctl`` in its name.
+
+Variable measuring time should be suffixed with the unit of time it is measured in:
+``_s`` for seconds, ``_ms`` for milliseconds, ``_us`` for microseconds, ``_ns`` for nanoseconds.
+
5) Typedefs
-----------
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v21 06/14] dmaengine: qcom: bam_dma: add support for BAM locking
From: Vinod Koul @ 2026-07-15 15:36 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Stephan Gerhold, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Bjorn Andersson, Peter Ujfalusi,
Michal Simek, Frank Li, Andy Gross, Neil Armstrong, dmaengine,
linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <CAMRc=MevqXga1u-XC8LYc3hnjjzmdESntsSGYP25XECeeySfJA@mail.gmail.com>
On 15-07-26, 14:43, Bartosz Golaszewski wrote:
> On Tue, 14 Jul 2026 11:49:14 +0200, Stephan Gerhold
> <stephan.gerhold@linaro.org> said:
> > On Mon, Jul 13, 2026 at 03:01:07PM +0200, Bartosz Golaszewski wrote:
> >> Add support for BAM pipe locking. To that end: when starting DMA on an RX
> >> channel - prepend the existing queue of issued descriptors with an
> >> additional "dummy" command descriptor with the LOCK bit set. Once the
> >> transaction is done (no more issued descriptors), issue one more dummy
> >> descriptor with the UNLOCK bit.
> >>
> >> We *must* wait until the transaction is signalled as done because we
> >> must not perform any writes into config registers while the engine is
> >> busy.
> >>
> >> The dummy writes must be issued into a scratchpad register of the client
> >> so provide a mechanism to communicate the right address via descriptor
> >> metadata.
> >>
> >> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >
> > Thanks for the fixes. The lock/unlock sequence looks good to me now,
> > I commented on a couple of minor things below that would be good to fix
> > (some of them are also reported by Sashiko).
> >
>
> Thanks.
>
> >> ---
> >> drivers/dma/qcom/bam_dma.c | 191 +++++++++++++++++++++++++++++++++++++--
> >> include/linux/dma/qcom_bam_dma.h | 14 +++
> >> 2 files changed, 198 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> >> index f3e713a5259c2c7c24cfdcec094814eb1202971a..f08549ee3872eece85884606d6ee9e540ee688ca 100644
> >> --- a/drivers/dma/qcom/bam_dma.c
> >> +++ b/drivers/dma/qcom/bam_dma.c
> >> [...]
> >> @@ -686,6 +702,35 @@ static int bam_slave_config(struct dma_chan *chan,
> >> return 0;
> >> }
> >>
> >> +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> >> +{
> >> + struct bam_chan *bchan = to_bam_chan(desc->chan);
> >> + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> >> + struct bam_desc_metadata *metadata = data;
> >> +
> >> + if (!data)
> >
> > Doesn't really matter much, but since the parameter exists you might as
> > well add
> >
> > && len == sizeof(*metadata)
> >
> > here to be sure.
> >
>
> Ok.
>
> >> + return -EINVAL;
> >> +
> >> + if (!bdata->pipe_lock_supported)
> >> + /*
> >> + * The client wants to use locking but this BAM version doesn't
> >> + * support it. Don't return an error here as this will stop the
> >> + * client from using DMA at all for no reason.
> >> + */
> >> + return 0;
> >> +
> >> + guard(spinlock_irqsave)(&bchan->vc.lock);
> >> +
> >> + bchan->scratchpad_addr = metadata->scratchpad_addr;
> >> + bchan->direction = metadata->direction;
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static const struct dma_descriptor_metadata_ops bam_metadata_ops = {
> >> + .attach = bam_metadata_attach,
> >> +};
> >
> > I'm not sure if we have discussed this before, but could we avoid
> > re-programming the scratchpad_addr all the time by placing it into
> > struct dma_slave_config -> peripheral_config? It still feels awkward to
> > me to place a global constant configuration value into per-descriptor
> > metadata.
The concept is that a dmaengine can handle multiple peripherals, so the
peripheral is always per desciptor
> Yes, this was discussed several versions ago. I went with using
> dmaengine_slave_config() until v11. I think Vinod or Dmitry requested we change
> it to the metadata.
metadata seems better fit for this.
> >> /**
> >> * bam_prep_slave_sg - Prep slave sg transaction
> >> *
> >> [...]
> >> @@ -802,6 +851,7 @@ static int bam_dma_terminate_all(struct dma_chan *chan)
> >> }
> >>
> >> vchan_get_all_descriptors(&bchan->vc, &head);
> >> + bchan->bam_locked = false;
> >
> > I wonder about the implications of this. If the LOCK descriptor was
> > already processed, will we cause a deadlock if we never submit the
> > UNLOCK descriptor? Or I guess bam_reset_channel() might reset the lock
> > as well?
Good point
--
~Vinod
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Eric Dumazet @ 2026-07-15 15:30 UTC (permalink / raw)
To: Leon Hwang
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <2dc3d52b-ce4a-411d-9c30-934318ee98b0@linux.dev>
On Wed, Jul 15, 2026 at 5:26 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> On 2026/7/15 23:15, Eric Dumazet wrote:
> > On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> [...]
>
> >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> >> index 61045a8886e4..4f1027173e95 100644
> >> --- a/net/ipv4/tcp_input.c
> >> +++ b/net/ipv4/tcp_input.c
> >> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
> >> /* When we get a reset we do this. */
> >> void tcp_reset(struct sock *sk, struct sk_buff *skb)
> >> {
> >> + const struct net *net = sock_net(sk);
> >> int err;
> >>
> >> trace_tcp_receive_reset(sk);
> >> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
> >> err = ECONNREFUSED;
> >> break;
> >> case TCP_CLOSE_WAIT:
> >> + /* RFC9293 3.10.7.4. Other States
> >> + * Second, check the RST bit:
> >> + * CLOSE-WAIT STATE
> >> + *
> >> + * If the RST bit is set, then any outstanding RECEIVEs and
> >> + * SEND should receive "reset" responses. All segment queues
> >> + * should be flushed. Users should also receive an unsolicited
> >> + * general "connection reset" signal. Enter the CLOSED state,
> >> + * delete the TCB, and return.
> >> + *
> >> + * If net.ipv4.tcp_purge_receive_queue is enabled,
> >> + * sk_receive_queue will be flushed too.
> >> + */
> >> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
> >> + struct tcp_sock *tp = tcp_sk(sk);
> >> +
> >> + skb_queue_purge(&sk->sk_receive_queue);
> >> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
> >> + WRITE_ONCE(tp->urg_data, 0);
> >> + sk_set_peek_off(sk, -1);
> >> + }
> >> err = EPIPE;
> >> break;
> >> case TCP_CLOSE:
> >> --
> >> 2.55.0
> >>
> >
> > My thoughts are:
> >
> > out_of_order_queue has been forgotten. skbs could be there and still
> > 'block devmem'
> >
> > WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
> > read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
> > So the application will not know a RST was received :/
> >
> > I think that BSD and linux implementations have historically retained
> > acknowledged,
> > buffered receive data upon RST to allow applications to drain data
> > already ACKed prior to the reset.
> >
> > Adding a narrow sysctl specifically for CLOSE_WAIT creates
> > inconsistent behavior across TCP states.
>
>
> Got it. I won't pursue this sysctl approach in the future. Thanks for
> the review.
My intention was not to kill your proposal, only to start a conversation...
^ permalink raw reply
* Re: [PATCH v5 00/23] Introduce SCMI Telemetry support
From: Cristian Marussi @ 2026-07-15 15:29 UTC (permalink / raw)
To: Subrahmanya Lingappa
Cc: Cristian Marussi, arm-scmi, linux-arm-kernel, linux-kernel,
linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford, brauner, david,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <CAPxK-6cE7QAnMxO843T_MhipsVed=q7M6yQG6q5mAknY+T91kw@mail.gmail.com>
On Wed, Jul 15, 2026 at 07:15:10PM +0530, Subrahmanya Lingappa wrote:
> Hi David, Cristian,
>
> Thanks, both. Fair points.
>
Hi Subrahmanya,
> On Fri, Jul 10, 2026 at 2:02 PM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
> >
> > On Tue, Jul 07, 2026 at 12:01:37PM +0530, Subrahmanya Lingappa wrote:
> > > Hi Cristian,
> >
[snip]
>
> I agree that asking this series to grow a generic telemetry subsystem now is
> too much. With only SCMI in-tree, it would be easy to create a "generic"
> interface that is really just SCMI with different names. I also agree that raw
> SHMTI is not just a debug path if the expected users are high-rate tooling.
>
> So let me narrow the ask.
>
> I am not asking for `drivers/telemetry/` in v6. I am asking that the SCMI
> chardev/UAPI not be tied too closely to the current SCMI core storage layout.
> In particular, I think v6 should try to:
>
> - copy descriptor/config/sample data through fixed and extensible UAPI
> structs, not structs mirroring SCMI internal objects;
If you mean by this adding a bit more of pad/reserved space scattered
here and there, it is not a problem; also, one thing that is still missing
and planned to be added is some ABI Versioning and related IOCTL,
should not this be enough to address future possible UAPI expansions ?
Regarding avoiding mapping internal SCMI object in the UAPI, I think I
am already NOT blindly sharing internal structures but instead I copy
explicitly internal representations into the UAPI fields....I think the
only exception to this is the sample (scmi_tlm_de_sample) that I take
care to keep aligned with the internals to avoid the overhead of the
double copy...but it seems one of the few pretty much general concept
that I felt confident to abstract no ?
...but of course this UAPI abstraction into which I copy the results
is mapped into SCMI inspired concepts/abstractions...for the reasons
we said....
> - treat DE IDs, group IDs and SHMTI IDs as protocol identifiers, not as
> implicit indexes into kernel arrays;
Not sure what you mean here... a shim layer used to acces info data
indirectly instead of the SCMI data structures ?
or some sort of layer/abstraction to be able to remap references
internally ? again it is not easy to imagine an abstraction without any
other example than SCMI...or you mean naming issue in the UAPI ?
> - keep the TDCF/SHMTI parsing and SCMI command handling behind small
> internal ops used by the chardev side;
well..if you refer to the telemetry_ops, this is an SCMI driver so it
has the structure of an SCMI driver, the Telemetry Operations exposed by
the core SCMI stack are the internal ops themselves that you ask for in
my opinion...I mean this is pretty much internal stuff that has nothing
to do with the UAPI itself and I imagine that when some future protocol
of yours, like the XXMI you mentioned, will appear you will write a new
driver on your own subsystem that will implement the UAPI itself for
your protocols (if you want to share that)...any possible future internal
reworking due to possible common abstractions on our side can be carried
out in the future...
> - document the config model explicitly: per SCMI instance, last writer wins,
> generation changes tell userspace that state changed;
> - document the mmap contract: length, offsets, cache attributes, lifetime,
> and reset/reconfiguration behaviour.
Completely agreed on this...Documentation is still lacking, including
extensive examples...I should have marked docs as RFC too...
>
> That keeps the ABI explicitly SCMI-specific and does not make SHMTI second
> class. It just avoids baking too much of today's SCMI implementation shape into
> the userspace contract.
>
> Cristian's point about policy being enforced by the SCMI server also makes
> sense to me. I am not suggesting Linux should second-guess that partitioning.
> Documenting the Linux-visible semantics is enough: what is shared per SCMI
> instance, what userspace may race with, and how generation/poll reports that.
Yes it will be documented too...in one of the future series.
>
> So I would reduce my earlier suggestion to: no generic framework required now,
> but please keep a clean provider/backend boundary inside the driver and leave
> some UAPI growth room. That should make a later common layer possible, if a
> second provider or an in-kernel user ever justifies it, without forcing this
> series to solve that problem today.
No problem for UAPI growth and possible compatibility visa reserved
space and ABI versioning, but I dont see how a very susbsystem specific
driver like this SCMI Telemetry driver can be made more generic in terms of
provider/backend...the provider here is indeed already separated by the usage
of the SCMI telemetry protocol operations exposed by the core SCMI stack...
I think in order to have multiple backend providers pluggable/interchangeable
at will without the need to write a new driver for ecah one would mean, again,
having some sort common framework...thing that seems premature, as agreed.
Thanks,
Cristian
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 15:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <CANn89iLyeAPNV2VHTM3w0-zpzjZNFy3aJDsVUERYyniLN4ub7A@mail.gmail.com>
On 2026/7/15 23:15, Eric Dumazet wrote:
> On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
[...]
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 61045a8886e4..4f1027173e95 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
>> /* When we get a reset we do this. */
>> void tcp_reset(struct sock *sk, struct sk_buff *skb)
>> {
>> + const struct net *net = sock_net(sk);
>> int err;
>>
>> trace_tcp_receive_reset(sk);
>> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
>> err = ECONNREFUSED;
>> break;
>> case TCP_CLOSE_WAIT:
>> + /* RFC9293 3.10.7.4. Other States
>> + * Second, check the RST bit:
>> + * CLOSE-WAIT STATE
>> + *
>> + * If the RST bit is set, then any outstanding RECEIVEs and
>> + * SEND should receive "reset" responses. All segment queues
>> + * should be flushed. Users should also receive an unsolicited
>> + * general "connection reset" signal. Enter the CLOSED state,
>> + * delete the TCB, and return.
>> + *
>> + * If net.ipv4.tcp_purge_receive_queue is enabled,
>> + * sk_receive_queue will be flushed too.
>> + */
>> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
>> + struct tcp_sock *tp = tcp_sk(sk);
>> +
>> + skb_queue_purge(&sk->sk_receive_queue);
>> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
>> + WRITE_ONCE(tp->urg_data, 0);
>> + sk_set_peek_off(sk, -1);
>> + }
>> err = EPIPE;
>> break;
>> case TCP_CLOSE:
>> --
>> 2.55.0
>>
>
> My thoughts are:
>
> out_of_order_queue has been forgotten. skbs could be there and still
> 'block devmem'
>
> WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
> read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
> So the application will not know a RST was received :/
>
> I think that BSD and linux implementations have historically retained
> acknowledged,
> buffered receive data upon RST to allow applications to drain data
> already ACKed prior to the reset.
>
> Adding a narrow sysctl specifically for CLOSE_WAIT creates
> inconsistent behavior across TCP states.
Got it. I won't pursue this sysctl approach in the future. Thanks for
the review.
Leon
^ permalink raw reply
* Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
From: Mathieu Poirier @ 2026-07-15 15:25 UTC (permalink / raw)
To: Shenwei Wang (OSS)
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn
In-Reply-To: <PAXPR04MB9185B1A3F16D82E8C0C76EE689F92@PAXPR04MB9185.eurprd04.prod.outlook.com>
On Tue, Jul 14, 2026 at 06:43:30PM +0000, Shenwei Wang (OSS) wrote:
>
>
> > -----Original Message-----
> > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Sent: Tuesday, July 14, 2026 11:36 AM
> > To: Shenwei Wang (OSS) <shenwei.wang@oss.nxp.com>
> > Cc: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> > Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> > Andersson <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > <festevam@gmail.com>; Shenwei Wang <shenwei.wang@nxp.com>; Peng Fan
> > <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> > remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> > kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Arnaud
> > POULIQUEN <arnaud.pouliquen@foss.st.com>; b-padhi@ti.com; Andrew Lunn
> > <andrew@lunn.ch>
> > Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg
> > bus
> >
> > On Tue, Jul 14, 2026 at 02:29:12PM +0000, Shenwei Wang (OSS) wrote:
> d
> > > > > + - 3: Both edge trigger
> > > > > + - 4: High level trigger
> > > > > + - 8: Low level trigger
> > > >
> > > > I'm in agreement with cmd 3, 4, 5 and 6.
> > > >
> > >
> > > How about cmd 2?
> >
> > Yes, I forgot cmd 2.
> >
> > >
> > > > > +
> > > > > +**Reply:**
> > > > > +
> > > > > +.. code-block:: none
> > > > > +
> > > > > + +------+--------+--------+
> > > > > + | 0x00 | 0x01 | 0x02 |
> > > > > + | 1 | status | 0 |
> > > > > + +------+--------+--------+
> > > > > +
> > > > > +- **status**:
> > > > > +
> > > > > + - 0: Ok
> > > > > + - 1: Error
> > > > > +
> > > > > +SET_WAKEUP (Cmd=16)
> > > > > +~~~~~~~~~~~~~~~~~~~
> > > >
> > > > I already commented on messages that are not part of the virtio-gpio
> > > > specification.
> > > >
> > >
> > > I don't believe virtio-gpio needs a SET_WAKEUP command.
> > >
> > > In the RPMSG case, SET_WAKEUP is required because it performs an
> > > operation on the remote processor, so the remote side must be explicitly
> > notified.
> >
> > What operations would that be?
> >
>
> The operation is enabling the line as a wakeup source. In practice, this involves configuring
> hardware-specific wakeup settings (e.g., register bits) on the remote processor, so the remote
> side must be explicitly notified through SET_WAKEUP.
>
As I said before, we are not enhancing the virtio-gpio specification. If the
functionality is not part of the specification, it is not part of this protocol.
>
> > >
> > > For virtio-gpio, however, everything is handled locally. The other
> > > side does not need to perform any action, so sending a SET_WAKEUP command
> > appears unnecessary.
> >
> > What is "everything"?
> >
>
> I mean masking, unmasking, and marking the interrupt as a wakeup source. All of
> these operations are handled on local processor.
There may be enough capability in your remote processor to do all that, but we
can't assume the same applies to all implementations. rpmsg-gpio is not about
inventing a new protocol or delegating actions to the remote processor. It is
about carrying virtio-gpio packets on top of RPMSG. It needs to operate
_exactly_ the same way as virtio-gpio.
>
> Shenwei
>
> > >
> > >
> > > > > +
> > > > > +**Request:**
> > > > > +
> > > > > +.. code-block:: none
> > > > > +
> > > > > + +------+------+------+------+------+------+------+------+
> > > > > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > > > > + | 1 | line | value |
> > > > > + +------+------+------+------+------+------+------+------+
> > > > > +
> > > > > +- **value**: Wakeup enable.
> > > > > +
> > > > > + The remote system should always aim to stay in a
> > > > > + power-efficient state by shutting down or clock-gating the GPIO
> > > > > + blocks that aren't in use. Since the remoteproc driver is
> > > > > + responsible for managing the power states of the remote
> > > > > + firmware, the GPIO driver does not require to know the firmware's
> > running states.
> > > > > +
> > > > > + When the wakeup bit is set, the remote firmware should
> > > > > + configure the line as a wakeup source. The firmware should send
> > > > > + the notification message to Linux after it is woken from the GPIO line.
> > > > > +
> > > > > + - 0: Disable wakeup from GPIO
> > > > > + - 1: Enable wakeup from GPIO
> > > > > +
> > > > > +**Reply:**
> > > > > +
> > > > > +.. code-block:: none
> > > > > +
> > > > > + +------+--------+--------+
> > > > > + | 0x00 | 0x01 | 0x02 |
> > > > > + | 1 | status | 0 |
> > > > > + +------+--------+--------+
> > > > > +
> > > > > +- **status**:
> > > > > +
> > > > > + - 0: Ok
> > > > > + - 1: Error
> > > > > +
> > > > > +Notification Message
> > > > > +--------------------
> > > >
> > > > "Interrupt Messages"
> > > >
> > > > > +
> > > > > +Notifications are sent by the remote core and they have
> > > > > +**Type=2 (GPIO_RPMSG_NOTIFY)**:
> > > > > +
> > > > > +When a GPIO line asserts an interrupt on the remote processor,
> > > > > +the firmware should immediately mask the corresponding interrupt
> > > > > +source and send a notification message to the Linux. Upon
> > > > > +completion of the interrupt handling on the Linux side, the
> > > > > +driver should issue a command **SET_IRQ_TYPE** to the firmware to
> > unmask the interrupt.
> > > > > +
> > > > > +A Notification message can arrive between a SEND and its REPLY
> > > > > +message, and the driver is expected to handle this scenario.
> > > > > +
> > > > > +.. code-block:: none
> > > > > +
> > > > > + +------+------+--------+
> > > > > + | 0x00 | 0x01 | 0x02 |
> > > > > + | 2 | line | trigger|
> > > > > + +------+------+--------+
> > > >
> > > > 2 things here:
> > > >
> > > > 1) You did not include messages that mask and unmask interrupts at
> > > > the driver side.
> > >
> > > Interrupt masking and unmasking are handled entirely on the local processor.
> > >
> > > When an interrupt occurs, the remote system masks the interrupt and
> > > then sends a notification to Linux. After Linux processes the
> > > notification, it sends a SET_IRQ_TYPE message back to the remote system,
> > which then unmasks the interrupt.
> >
> > This is the kind of information that should be part of this documentation.
> >
> > >
> > > Thanks,
> > > Shenwei
> > >
> > > >
> > > > 2) We are carrying virtio-gpio messages on top of RPMSG and as such,
> > > > this whole protocol should be about thar:
> > > >
> > > > +------+------+--------+--------
> > > > | 0x00 | payload |
> > > > | Q | |
> > > > +------+------+--------+--------
> > > >
> > > > Q = 0 requestq
> > > > Q = 1 eventq
> > > >
> > > > The "payload" part is simply the format of the messages as found in
> > > > the virtio- gpio specification. From there, the only thing left to
> > > > mention is which messages are not supported, i.e get line names.
> > > >
> > > > > +
> > > > > +- **line**: The GPIO line (pin) index of the port.
> > > > > +
> > > > > +- **trigger**: Optional parameter to indicate the trigger event type.
> > > >
> > > > Not part of the spec - remove.
> > > >
> > > > Given the refactoring work that is still needed, I will not look at
> > > > the implementation.
> > > >
> > > > Thanks,
> > > > Mathieu
> > > >
> > > > > +
> > > > > diff --git a/Documentation/driver-api/gpio/index.rst
> > > > > b/Documentation/driver-api/gpio/index.rst
> > > > > index bee58f709b9a..e5eb1f82f01f 100644
> > > > > --- a/Documentation/driver-api/gpio/index.rst
> > > > > +++ b/Documentation/driver-api/gpio/index.rst
> > > > > @@ -16,6 +16,7 @@ Contents:
> > > > > drivers-on-gpio
> > > > > bt8xxgpio
> > > > > pca953x
> > > > > + gpio-rpmsg
> > > > >
> > > > > Core
> > > > > ====
> > > > > --
> > > > > 2.43.0
> > > > >
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Eric Dumazet @ 2026-07-15 15:15 UTC (permalink / raw)
To: Leon Hwang
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260715145328.54597-2-leon.hwang@linux.dev>
On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
> address an unreleased SKBs issue related to TCP sockets.
>
> Issue:
> When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
> current implementation does not clear the socket's receive queue. This
> causes SKBs in the queue to remain allocated until the socket is
> explicitly closed by the application. As a consequence:
>
> 1. The page pool pages held by these SKBs are not released.
> 2. The associated page pool cannot be freed.
>
> RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
> CLOSE_WAIT state, "all segment queues should be flushed." However, the
> current implementation does not flush the receive queue.
>
> Solution:
> Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
> when enabled, causes the kernel to purge the receive queue when a RST
> packet is received in CLOSE_WAIT state. This allows immediate release
> of SKBs and their associated memory resources.
>
> The feature is disabled by default to maintain backward compatibility
> with existing behavior.
>
> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> ---
> Documentation/networking/ip-sysctl.rst | 18 +++++++++++++++
> .../net_cachelines/netns_ipv4_sysctl.rst | 1 +
> include/net/netns/ipv4.h | 1 +
> net/ipv4/sysctl_net_ipv4.c | 9 ++++++++
> net/ipv4/tcp_input.c | 22 +++++++++++++++++++
> 5 files changed, 51 insertions(+)
>
> diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
> index 208f46967ee5..abbee0326f15 100644
> --- a/Documentation/networking/ip-sysctl.rst
> +++ b/Documentation/networking/ip-sysctl.rst
> @@ -1448,6 +1448,24 @@ tcp_rto_max_ms - INTEGER
>
> Default: 120,000
>
> +tcp_purge_receive_queue - BOOLEAN
> + When a socket in the TCP_CLOSE_WAIT state receives a RST packet, the
> + default behavior is to not clear its receive queue. As a result,
> + any SKBs in the queue are not freed until the socket is closed.
> + Consequently, the pages held by these SKBs are not released, which
> + can also prevent the associated page pool from being freed.
> +
> + If enabled, the receive queue is purged upon receiving the RST,
> + allowing the SKBs and their associated memory to be released
> + promptly.
> +
> + Possible values:
> +
> + - 0 (disabled)
> + - 1 (enabled)
> +
> + Default: 0 (disabled)
> +
> UDP variables
> =============
>
> diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
> index 3dc03bff739e..2945de40ad78 100644
> --- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
> +++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
> @@ -126,6 +126,7 @@ unsigned_long sysctl_tcp_comp_sack_delay_ns
> unsigned_long sysctl_tcp_comp_sack_slack_ns __tcp_ack_snd_check
> int sysctl_max_syn_backlog
> int sysctl_tcp_fastopen
> +u8 sysctl_tcp_purge_receive_queue
> struct_tcp_congestion_ops tcp_congestion_control init_cc
> struct_tcp_fastopen_context tcp_fastopen_ctx
> unsigned_int sysctl_tcp_fastopen_blackhole_timeout
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index cb7f8bf15671..ab9b92807d9f 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -222,6 +222,7 @@ struct netns_ipv4 {
> u8 sysctl_tcp_nometrics_save;
> u8 sysctl_tcp_no_ssthresh_metrics_save;
> u8 sysctl_tcp_workaround_signed_windows;
> + u8 sysctl_tcp_purge_receive_queue;
> int sysctl_tcp_challenge_ack_limit;
> u8 sysctl_tcp_min_tso_segs;
> u8 sysctl_tcp_reflect_tos;
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index ca1180dba1de..82412fd98e0e 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -1652,6 +1652,15 @@ static struct ctl_table ipv4_net_table[] = {
> .extra1 = SYSCTL_ONE_THOUSAND,
> .extra2 = &tcp_rto_max_max,
> },
> + {
> + .procname = "tcp_purge_receive_queue",
> + .data = &init_net.ipv4.sysctl_tcp_purge_receive_queue,
> + .maxlen = sizeof(u8),
> + .mode = 0644,
> + .proc_handler = proc_dou8vec_minmax,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_ONE,
> + },
> };
>
> static __net_init int ipv4_sysctl_init_net(struct net *net)
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 61045a8886e4..4f1027173e95 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
> /* When we get a reset we do this. */
> void tcp_reset(struct sock *sk, struct sk_buff *skb)
> {
> + const struct net *net = sock_net(sk);
> int err;
>
> trace_tcp_receive_reset(sk);
> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
> err = ECONNREFUSED;
> break;
> case TCP_CLOSE_WAIT:
> + /* RFC9293 3.10.7.4. Other States
> + * Second, check the RST bit:
> + * CLOSE-WAIT STATE
> + *
> + * If the RST bit is set, then any outstanding RECEIVEs and
> + * SEND should receive "reset" responses. All segment queues
> + * should be flushed. Users should also receive an unsolicited
> + * general "connection reset" signal. Enter the CLOSED state,
> + * delete the TCB, and return.
> + *
> + * If net.ipv4.tcp_purge_receive_queue is enabled,
> + * sk_receive_queue will be flushed too.
> + */
> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
> + struct tcp_sock *tp = tcp_sk(sk);
> +
> + skb_queue_purge(&sk->sk_receive_queue);
> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
> + WRITE_ONCE(tp->urg_data, 0);
> + sk_set_peek_off(sk, -1);
> + }
> err = EPIPE;
> break;
> case TCP_CLOSE:
> --
> 2.55.0
>
My thoughts are:
out_of_order_queue has been forgotten. skbs could be there and still
'block devmem'
WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
So the application will not know a RST was received :/
I think that BSD and linux implementations have historically retained
acknowledged,
buffered receive data upon RST to allow applications to drain data
already ACKed prior to the reset.
Adding a narrow sysctl specifically for CLOSE_WAIT creates
inconsistent behavior across TCP states.
Thanks.
^ permalink raw reply
* Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
From: Mathieu Poirier @ 2026-07-15 15:10 UTC (permalink / raw)
To: Shenwei Wang (OSS)
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn
In-Reply-To: <PAXPR04MB918568AE7B2364EC9D16427689F92@PAXPR04MB9185.eurprd04.prod.outlook.com>
On Tue, Jul 14, 2026 at 07:04:08PM +0000, Shenwei Wang (OSS) wrote:
>
>
> > -----Original Message-----
> > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Sent: Monday, July 13, 2026 12:17 PM
> > To: Shenwei Wang (OSS) <shenwei.wang@oss.nxp.com>
> > Cc: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> > Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> > Andersson <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > <festevam@gmail.com>; Shenwei Wang <shenwei.wang@nxp.com>; Peng Fan
> > <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> > remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> > kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Arnaud
> > POULIQUEN <arnaud.pouliquen@foss.st.com>; b-padhi@ti.com; Andrew Lunn
> > <andrew@lunn.ch>
> > Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg
> > bus
> >
> > > +
> > > +The RPMSG message consists of a 8-byte packet with the following layout:
> > > +
> > > +.. code-block:: none
> > > +.. code-block:: none
> > > +
> > > + +------+------+--------+
> > > + | 0x00 | 0x01 | 0x02 |
> > > + | 2 | line | trigger|
> > > + +------+------+--------+
> >
> > 2 things here:
> >
> > 1) You did not include messages that mask and unmask interrupts at the driver
> > side.
> >
> > 2) We are carrying virtio-gpio messages on top of RPMSG and as such, this whole
> > protocol should be about thar:
> >
> > +------+------+--------+--------
> > | 0x00 | payload |
> > | Q | |
> > +------+------+--------+--------
> >
> > Q = 0 requestq
> > Q = 1 eventq
> >
> > The "payload" part is simply the format of the messages as found in the virtio-
> > gpio specification. From there, the only thing left to mention is which messages
> > are not supported, i.e get line names.
> >
> > > +
> > > +- **line**: The GPIO line (pin) index of the port.
> > > +
> > > +- **trigger**: Optional parameter to indicate the trigger event type.
> >
> > Not part of the spec - remove.
> >
>
> The two fields above are required for rpmsg-gpio, but not for virtio-gpio.
I agree that the line is required but not the trigger. The driver (using the
same terminology as the specification) knows what trigger the pin has been
configured for. Adding the trigger information to the interrupt notification is
redundant.
>
> In the rpmsg-gpio case, interrupt detection and handling occur on the remote processor. The
> interrupt information (such as the GPIO line and trigger type) must therefore be sent to Linux
> through this notification message.
>
> In contrast, for virtio-gpio, interrupt handling is performed on the local processor. Since Linux already
> has all the necessary interrupt context, the information is not needed.
>
> Shenwei
>
> > Given the refactoring work that is still needed, I will not look at the
> > implementation.
> >
> > Thanks,
> > Mathieu
> >
> > > +
> > > diff --git a/Documentation/driver-api/gpio/index.rst
> > > b/Documentation/driver-api/gpio/index.rst
> > > index bee58f709b9a..e5eb1f82f01f 100644
> > > --- a/Documentation/driver-api/gpio/index.rst
> > > +++ b/Documentation/driver-api/gpio/index.rst
> > > @@ -16,6 +16,7 @@ Contents:
> > > drivers-on-gpio
> > > bt8xxgpio
> > > pca953x
> > > + gpio-rpmsg
> > >
> > > Core
> > > ====
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* Re: [PATCH v2 0/4] mm/hmm: Clarify notifier retry state and scope HMM timeouts
From: Jason Gunthorpe @ 2026-07-15 15:02 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: David Hildenbrand (Arm), airlied, akhilesh, akpm, corbet, dakr,
kees, leon, liam, lizhi.hou, ljs, lyude, maarten.lankhorst,
mamin506, mhocko, mripard, nouveau, ogabbay, oleg, rppt, shuah,
simona, skhan, surenb, tzimmermann, vbabka, dri-devel, linux-mm,
linux-doc, linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alecaJ1FUso39D9k@skinsburskii>
On Wed, Jul 15, 2026 at 07:42:48AM -0700, Stanislav Kinsburskii wrote:
> > > Stanislav Kinsburskii (4):
> > > fixup! mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support
> > > fixup! drm/nouveau: use hmm_range_fault_unlocked_timeout() for SVM faults
> > > fixup! accel/amdxdna: use hmm_range_fault_unlocked_timeout() for range population
> > > fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults
> >
> > Why a fixup series instead of properly resending the full thing?
> >
>
> The goal was to get a Sashiko review, and v8 has already been applied to
> both `mm-new` and `linux-next`.
I think if you send the whole thing with a base-commit tag that
specifies a real base commit in linux-next sashiko should work
Jason
^ permalink raw reply
* [PATCH v3 1/1] Documentation: real-time: Add kernel configuration guide
From: Ahmed S. Darwish @ 2026-07-15 15:01 UTC (permalink / raw)
To: Jonathan Corbet, Clark Williams, Steven Rostedt, linux-rt-devel
Cc: Matthew Wilcox, Sebastian Andrzej Siewior, John Ogness,
Derek Barbosa, linux-doc, linux-kernel, Ahmed S. Darwish
In-Reply-To: <20260715150147.225715-1-darwi@linutronix.de>
Add a configuration guide for real-time kernels.
List all Kconfig options that are recommended to be either enabled or
disabled. Explicitly add a table of contents at the top of the document,
so that all the options can be seen in a glance.
Whenever appropriate, link to other kernel guides; e.g. cpuidle, cpufreq,
power management, and no_hz.
Add a summary at the end of the document warning users that there is a no
"one size fits all solution" for configuring a real-time system.
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
---
Documentation/core-api/real-time/index.rst | 1 +
.../real-time/kernel-configuration.rst | 313 ++++++++++++++++++
2 files changed, 314 insertions(+)
create mode 100644 Documentation/core-api/real-time/kernel-configuration.rst
diff --git a/Documentation/core-api/real-time/index.rst b/Documentation/core-api/real-time/index.rst
index f08d2395a22c..a17a3dec535c 100644
--- a/Documentation/core-api/real-time/index.rst
+++ b/Documentation/core-api/real-time/index.rst
@@ -15,3 +15,4 @@ the required changes compared to a non-PREEMPT_RT configuration.
differences
hardware
architecture-porting
+ kernel-configuration
diff --git a/Documentation/core-api/real-time/kernel-configuration.rst b/Documentation/core-api/real-time/kernel-configuration.rst
new file mode 100644
index 000000000000..008d706f36cd
--- /dev/null
+++ b/Documentation/core-api/real-time/kernel-configuration.rst
@@ -0,0 +1,313 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Real-Time Kernel configuration
+==============================
+
+.. contents:: Table of Contents
+ :depth: 3
+ :local:
+
+Introduction
+============
+
+This document lists the kernel configuration options that might affect a
+real-time kernel's worst-case latency. It is intended for system integrators.
+
+Configuration options
+=====================
+
+``CONFIG_CPU_FREQ``
+-------------------
+
+:Expectation: enabled
+:Severity: *high*
+
+The CPU frequency scaling subsystem ensures that the processor can operate
+at its maximum supported frequency. While, in general, bootloaders are
+tasked with setting the CPU clock to the highest speed on boot, some do
+not. It is thus desirable to keep this option enabled.
+
+.. caution::
+
+ A real-time kernel is not about being "as fast as possible", however
+ real-time requirements may demand that the CPU is clocked at a
+ particular speed.
+
+``CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE``
+-------------------------------------------
+
+:Expectation: enabled
+:Severity: *high*
+
+Real-Time workloads expect a fixed CPU frequency during execution. Using
+the performance governor is an easy way to achieve that purely from kernel
+configuration.
+
+This is not a blanket rule. Some setups might prefer to clock the CPU to
+lower speeds due to thermal packaging or other requirements. The key is
+that the CPU frequency remains constant once set.
+
+``CONFIG_CPU_IDLE``
+-------------------
+
+:Expectation: enabled
+:Severity: *info*
+
+CPU idle states (C-states) allow the processor to enter low-power modes
+during periods of inactivity. Very-low CPU idle states may require
+flushing the CPU caches and lowering or disabling the clocking. This can
+lower power consumption, but it also increases the entry and exit latency
+from such states.
+
+While disabling this option eliminates cpuidle-related latencies, doing so
+can significantly impact hardware longevity, warranty, and thermal
+behavior. Users should cap the maximum C-state to C1 instead. For ACPI
+platforms, this can be achieved by using the boot parameter [1]_::
+
+ processor.max_cstate=1
+
+Higher C-states can be acceptable depending on the user workload's latency
+requirements. For ACPI-based platforms, use the ``cpupower idle-info``
+command to inspect the available idle states.
+
+For more information, please see:
+
+- ``linux/tools/power/cpupower``
+- :doc:`/admin-guide/pm/cpuidle`
+- :doc:`/admin-guide/pm/index`
+
+``CONFIG_DRM``
+--------------
+
+:Expectation: disabled
+:Severity: *info*
+
+GPU-accelerated workloads can share system resources with the CPU,
+including last-level cache (LLC) and memory bandwidth. Modern integrated
+GPUs optimize graphics performance at the expense of CPU determinism.
+
+Examples of affected platforms:
+
+- Intel processors with integrated graphics (Gen9 and later)
+- AMD APUs with Radeon Graphics
+- Xilinx Zynq UltraScale+ MPSoC EG/EV series
+
+If graphics workloads must run alongside real-time tasks, users must
+conduct thorough stress testing using tools like ``glmark2`` while
+measuring the overall system latency.
+
+For more information, please check:
+
+- :doc:`Regarding hardware (System memory and cache) </core-api/real-time/hardware>`
+- :doc:`/filesystems/resctrl`
+- `Real-Time and Graphics: A Contradiction?`_
+
+``CONFIG_EFI_DISABLE_RUNTIME``
+------------------------------
+
+:Expectation: enabled
+:Severity: *medium*
+
+EFI is the standard boot and firmware interface for multiple
+architectures. EFI runtime services provide callback functions to be
+called from the kernel; e.g., as utilized by (``CONFIG_EFI_VARS*``) or
+(``CONFIG_RTC_DRV_EFI``). For the former, the kernel calls into EFI to
+update the EFI variables.
+
+Calling into EFI means invoking firmware callbacks. During such
+invocations, the system might not be able to react to interrupts and will
+thus not be able to perform a context switch. This can cause significant
+latency spikes for the real-time system.
+
+``CONFIG_PREEMPT_RT`` enables this option by default. If this option is
+manually disabled at build time, the following boot parameter [1]_ may be
+used to disable EFI runtime at boot up::
+
+ efi=noruntime
+
+Alternatively, confine EFI runtime service calls to a housekeeping CPU by
+restricting the ``efi_runtime`` workqueue CPU affinity. For example, set
+that workqueue's affinity to CPU #0 and pin your RT tasks to a different
+CPU range. Note that exposing workqueues through sysfs requires having
+``CONFIG_WQ_SYSFS`` enabled. See :doc:`/core-api/workqueue`.
+
+``CONFIG_NO_HZ`` / ``CONFIG_NO_HZ_FULL``
+----------------------------------------
+
+:Expectation: disabled
+:Severity: *medium*
+
+Tickless operation can increase kernel-to-userspace transition latency due
+to the extra accounting and state book-keeping.
+
+*Guidance by real-time workload type:*
+
+- For periodic workloads; e.g., control loops executing every 100 µs, avoid
+ ``NO_HZ`` modes. Consistent kernel ticks are preferable.
+
+- For computation-intensive workloads; e.g. extended userspace execution,
+ ``NO_HZ_FULL`` may be beneficial. In such cases, users should offload
+ the kernel housekeeping to dedicated CPUs and isolate compute cores.
+
+See also :doc:`/timers/no_hz`.
+
+``CONFIG_PREEMPT_RT``
+---------------------
+
+:Expectation: enabled
+:Severity: **fatal**
+
+This option must be enabled, or the resulting kernel will not be fully
+preemptible and real-time capable.
+
+``CONFIG_TRACING`` (and tracing options)
+----------------------------------------
+
+:Expectation: enabled
+:Severity: *info*
+
+Shipping kernels with tracing support enabled (but not actively running) is
+highly recommended. This will allow the users to extract more information
+if latency problems arise. Nonetheless, some tracers do incur latency
+overhead by just being enabled; see :ref:`tracers`.
+
+.. caution::
+
+ Users should *not* make use of tracers or trace events during production
+ real-time kernel operation as they can add considerable overhead and
+ degrade the system's latency.
+
+Non-performance CPU frequency governors
+---------------------------------------
+
+:Expectation: disabled
+:Severity: *medium*
+
+To ensure reproducible system latency measurements, disable the
+non-``PERFORMANCE`` CPU frequency governors when possible. This avoids the
+risk of unknown userspace tasks implicitly or explicitly setting a
+different CPU frequency governor, and thus achieving different latency
+results across the system's runtime.
+
+If disabling other frequency governors is not an option, then
+``CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE`` should be enabled. In that case,
+users should set a *stable* CPU frequency setting during the system
+runtime, as changing the CPU frequency will increase the system latency and
+affect latency measurements reproducibility. If a lower CPU frequency is
+desired, then ``CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE`` should be set.
+
+The ``ONDEMAND`` CPU frequency governor should *not* be enabled in a
+real-time system since it dramatically affects determinism depending on the
+workload.
+
+For more information, please check :doc:`/admin-guide/pm/cpufreq`.
+
+Kernel Debug Options
+====================
+
+Most kernel debug options add runtime overhead that increases the
+worst-case latency.
+
+.. caution::
+
+ During development and early testing, users are encouraged to run their
+ real-time workloads and peripherals with lockdep (:ref:`lockdep`) and
+ other kernel debug options enabled, for a considerable amount of time.
+ Such workloads might trigger kernel code paths that were not triggered
+ during the internal Linux real-time kernel development, thus helping to
+ uncover locking and other types of kernel bugs.
+
+Problematic debug options
+-------------------------
+
+.. _tracers:
+
+``CONFIG_IRQSOFF_TRACER`` and ``CONFIG_PREEMPT_TRACER``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Severity: *high*
+
+These tracers do incur measurable latency overhead even when tracing is not
+currently active.
+
+``CONFIG_LOCKUP_DETECTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Severity: *high*
+
+The lockup detector creates kernel timer callbacks that execute every few
+seconds, in hard-IRQ context, even on real-time kernels. These periodic
+interrupts can cause latency spikes.
+
+Users should use hardware watchdogs instead, which will provide a similar
+functionality without the software-induced latency.
+
+.. _lockdep:
+
+``CONFIG_PROVE_LOCKING``
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Severity: *high*
+
+Proving the correctness of all kernel locking adds substantial overhead
+and significantly increases worst-case latency.
+
+Allowed kernel debug options
+----------------------------
+
+Kernel debug options which are not included in this list should be enabled
+with caution, after extensive auditing of their impact on system latency.
+
+``CONFIG_DEBUG_ATOMIC_SLEEP``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This sanity check catches common kernel programming errors with
+a tolerable latency cost.
+
+``CONFIG_DEBUG_BUGVERBOSE``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This improves the debugging capabilities without affecting normal
+operation latency.
+
+``CONFIG_DEBUG_FS``
+^^^^^^^^^^^^^^^^^^^
+
+This is safe to include in real-time kernels, *provided that debugfs is
+not accessed during production runtime*.
+
+``CONFIG_DEBUG_INFO``
+^^^^^^^^^^^^^^^^^^^^^
+
+This increases the kernel image size but has no latency impact. It is
+also essential for meaningful crash dumps and profiling.
+
+``CONFIG_DEBUG_KERNEL``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Meta-option which allows debug features to be enabled. This configuration
+option has no runtime impact, but be aware of any debug features that it
+may have allowed to be enabled.
+
+Summary
+=======
+
+There is no "one size fits all" solution for configuring a real-time Linux
+system. Beginning with the system real-time requirements, integrators
+must consider the features and functions of the system's hardware, kernel,
+and userspace. All such components must be properly configured in order
+to establish and constrain the system's maximum latency.
+
+With that in mind, any incorrect real-time kernel configuration could cause
+a new maximum latency that shows up at the wrong time and is catastrophic
+for the real-time system's latency.
+
+References
+==========
+
+.. [1] See :doc:`/admin-guide/kernel-parameters`
+
+.. _development work: https://lore.kernel.org/r/20260227170103.4042157-1-bigeasy@linutronix.de
+
+.. _Real-Time and Graphics\: A Contradiction?: https://web.archive.org/web/20221025085614/https://linutronix.de/PDF/Realtime_and_graphics-acontradiction2021.pdf
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/1] Documentation: Add real-time kernel configuration guide
From: Ahmed S. Darwish @ 2026-07-15 15:01 UTC (permalink / raw)
To: Jonathan Corbet, Clark Williams, Steven Rostedt, linux-rt-devel
Cc: Matthew Wilcox, Sebastian Andrzej Siewior, John Ogness,
Derek Barbosa, linux-doc, linux-kernel, Ahmed S. Darwish
Hi,
There is a no "one size fits all" solution for configuring a PREEMPT_RT
kernel.
Intorduce a PREEMPT_RT kernel configuration guide to better help system
developers and integrators.
Changelog v3
------------
CONFIG_EFI_DISABLE_RUNTIME: Mention that system integrators can now assign
the efi_runtime workqueue CPU affinity, then safely pin RT tasks on a
different CPU range.
Changelog v2
------------
https://msgid.link/20260414174159.1271171-1-darwi@linutronix.de
Handle Rostedt remarks:
- Better reword certain paragraphs and statements
- Warn about enabling CONFIG_IRQSOFF_TRACER and CONFIG_PREEMPT_TRACER
Handle Wilcox remarks:
- Remove ToC comment + minor rewording
Changelog v1
------------
https://msgid.link/20260305205023.361530-1-darwi@linutronix.de
Thanks,
8<-----
Ahmed S. Darwish (1):
Documentation: real-time: Add kernel configuration guide
Documentation/core-api/real-time/index.rst | 1 +
.../real-time/kernel-configuration.rst | 313 ++++++++++++++++++
2 files changed, 314 insertions(+)
create mode 100644 Documentation/core-api/real-time/kernel-configuration.rst
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
--
2.54.0
^ permalink raw reply
* [linux-next:master] [crypto] 2f204fe718: stress-ng.af-alg.ops_per_sec 113.7% improvement
From: kernel test robot @ 2026-07-15 15:00 UTC (permalink / raw)
To: Eric Biggers
Cc: oe-lkp, lkp, Herbert Xu, linux-doc, linux-crypto, oliver.sang
Hello,
we don't have enough knowledge to deeply analyze the impact of this commit
to stress-ng.af-alg performance tests.
along with the major kpi improvement:
7756377 +113.7% 16578454 stress-ng.af-alg.ops_per_sec
we also noticed lots of misc tests seem have changes, e.g.
697423 -9.5% 630908 ± 2% stress-ng.af-alg.aes_cipher_ops/sec
245103 -100.0% 0.00 stress-ng.af-alg.blowfish_cipher_ops/sec
369646 -100.0% 0.00 stress-ng.af-alg.camellia_cipher_ops/sec
162192 -100.0% 0.00 stress-ng.af-alg.cast5_cipher_ops/sec
115113 -100.0% 0.00 stress-ng.af-alg.cast6_cipher_ops/sec
we don't know if these are expected behavior upon 2f204fe718.
so this report is just FYI what we observed in our tests.
kernel test robot noticed a 113.7% improvement of stress-ng.af-alg.ops_per_sec on:
commit: 2f204fe718f5bf519013cc2536ad7bb2cbb51661 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
testcase: stress-ng
config: x86_64-rhel-9.4
compiler: gcc-14
test machine: 256 threads 2 sockets Intel(R) Xeon(R) 6768P CPU @ 2.4GHz (Granite Rapids) with 64G memory
parameters:
nr_threads: 100%
testtime: 60s
test: af-alg
cpufreq_governor: performance
In addition to that, the commit also has significant impact on the following tests:
+------------------+-----------------------------------------------------------+
| testcase: change | stress-ng: stress-ng.af-alg.ops_per_sec 94.8% improvement |
| test parameters | cpufreq_governor=performance |
| | nr_threads=100% |
| | test=af-alg |
| | testtime=60s |
+------------------+-----------------------------------------------------------+
Details are as below:
-------------------------------------------------------------------------------------------------->
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260715/202607152204.a0a3bf98-lkp@intel.com
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
gcc-14/performance/x86_64-rhel-9.4/100%/debian-13-x86_64-20250902.cgz/lkp-gnr-2sp4/af-alg/stress-ng/60s
commit:
7e28b0a5c4 ("crypto: qce - Remove unsafe/deprecated algorithms")
2f204fe718 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
7e28b0a5c4b7d075 2f204fe718f5bf519013cc2536a
---------------- ---------------------------
%stddev %change %stddev
\ | \
697423 -9.5% 630908 ± 2% stress-ng.af-alg.aes_cipher_ops/sec
245103 -100.0% 0.00 stress-ng.af-alg.blowfish_cipher_ops/sec
369646 -100.0% 0.00 stress-ng.af-alg.camellia_cipher_ops/sec
162192 -100.0% 0.00 stress-ng.af-alg.cast5_cipher_ops/sec
115113 -100.0% 0.00 stress-ng.af-alg.cast6_cipher_ops/sec
695785 -4.5% 664436 ± 2% stress-ng.af-alg.cbc_aes_skcipher_ops/sec
238486 -100.0% 0.00 stress-ng.af-alg.cbc_blowfish_skcipher_ops/sec
360669 -100.0% 0.00 stress-ng.af-alg.cbc_camellia_skcipher_ops/sec
164699 -100.0% 0.00 stress-ng.af-alg.cbc_cast5_skcipher_ops/sec
116735 -100.0% 0.00 stress-ng.af-alg.cbc_cast6_skcipher_ops/sec
65406 -17.9% 53687 stress-ng.af-alg.cbc_des_skcipher_ops/sec
320814 -100.0% 0.00 stress-ng.af-alg.cbc_serpent_skcipher_ops/sec
69021 -100.0% 0.00 stress-ng.af-alg.cbc_sm4_skcipher_ops/sec
214626 -100.0% 0.00 stress-ng.af-alg.cbc_twofish_skcipher_ops/sec
642571 -100.0% 0.00 stress-ng.af-alg.chacha20_skcipher_ops/sec
891131 -100.0% 0.00 stress-ng.af-alg.cipher_null_cipher_ops/sec
1337159 -100.0% 0.00 stress-ng.af-alg.crc32_shash_ops/sec
1501487 -100.0% 0.00 stress-ng.af-alg.crc32c_shash_ops/sec
761754 -8.9% 694046 ± 2% stress-ng.af-alg.ctr_aes_skcipher_ops/sec
91060 -100.0% 0.00 stress-ng.af-alg.ctr_blowfish_skcipher_ops/sec
104238 -100.0% 0.00 stress-ng.af-alg.ctr_camellia_skcipher_ops/sec
115937 -100.0% 0.00 stress-ng.af-alg.ctr_cast5_skcipher_ops/sec
89670 -100.0% 0.00 stress-ng.af-alg.ctr_cast6_skcipher_ops/sec
28897 -100.0% 0.00 stress-ng.af-alg.ctr_des3_ede_skcipher_ops/sec
72715 -100.0% 0.00 stress-ng.af-alg.ctr_des_skcipher_ops/sec
74812 -100.0% 0.00 stress-ng.af-alg.ctr_serpent_skcipher_ops/sec
79546 -100.0% 0.00 stress-ng.af-alg.ctr_sm4_skcipher_ops/sec
145591 -100.0% 0.00 stress-ng.af-alg.ctr_twofish_skcipher_ops/sec
671291 -100.0% 0.00 stress-ng.af-alg.cts_cbc_aes_skcipher_ops/sec
68084 -100.0% 0.00 stress-ng.af-alg.cts_cbc_sm4_skcipher_ops/sec
29465 -100.0% 0.00 stress-ng.af-alg.des3_ede_cipher_ops/sec
75277 -4.0% 72278 stress-ng.af-alg.des_cipher_ops/sec
699558 -9.3% 634761 stress-ng.af-alg.ecb_aes_skcipher_ops/sec
246967 -100.0% 0.00 stress-ng.af-alg.ecb_blowfish_skcipher_ops/sec
369920 -100.0% 0.00 stress-ng.af-alg.ecb_camellia_skcipher_ops/sec
163784 -100.0% 0.00 stress-ng.af-alg.ecb_cast5_skcipher_ops/sec
115786 -100.0% 0.00 stress-ng.af-alg.ecb_cast6_skcipher_ops/sec
896443 -100.0% 0.00 stress-ng.af-alg.ecb_cipher_null_skcipher_ops/sec
29501 -100.0% 0.00 stress-ng.af-alg.ecb_des3_ede_skcipher_ops/sec
75654 -2.8% 73539 stress-ng.af-alg.ecb_des_skcipher_ops/sec
326245 -100.0% 0.00 stress-ng.af-alg.ecb_serpent_skcipher_ops/sec
81526 -100.0% 0.00 stress-ng.af-alg.ecb_sm4_skcipher_ops/sec
215554 -100.0% 0.00 stress-ng.af-alg.ecb_twofish_skcipher_ops/sec
720125 ± 3% -100.0% 0.00 stress-ng.af-alg.gcm_aes_aead_ops/sec
72857 -100.0% 0.00 stress-ng.af-alg.gcm_sm4_aead_ops/sec
532.66 -100.0% 0.00 stress-ng.af-alg.jitterentropy_rng_rng_ops/sec
527374 -100.0% 0.00 stress-ng.af-alg.lrw_aes_skcipher_ops/sec
315024 -100.0% 0.00 stress-ng.af-alg.lrw_camellia_skcipher_ops/sec
109568 -100.0% 0.00 stress-ng.af-alg.lrw_cast6_skcipher_ops/sec
283462 -100.0% 0.00 stress-ng.af-alg.lrw_serpent_skcipher_ops/sec
194288 -100.0% 0.00 stress-ng.af-alg.lrw_twofish_skcipher_ops/sec
867883 -11.8% 765839 ± 2% stress-ng.af-alg.md4_shash_ops/sec
673309 -2.8% 654759 stress-ng.af-alg.md5_shash_ops/sec
4.651e+08 +113.8% 9.941e+08 stress-ng.af-alg.ops
7756377 +113.7% 16578454 stress-ng.af-alg.ops_per_sec
735183 -100.0% 0.00 stress-ng.af-alg.rfc3686_ctr_aes_skcipher_ops/sec
360499 -100.0% 0.00 stress-ng.af-alg.rmd160_shash_ops/sec
328809 -100.0% 0.00 stress-ng.af-alg.serpent_cipher_ops/sec
887090 -4.6% 846645 ± 2% stress-ng.af-alg.sha1_shash_ops/sec
910035 -3.3% 879831 stress-ng.af-alg.sha224_shash_ops/sec
913992 -3.4% 883116 stress-ng.af-alg.sha256_shash_ops/sec
221685 -100.0% 0.00 stress-ng.af-alg.sha3-384_shash_ops/sec
165917 -100.0% 0.00 stress-ng.af-alg.sha3-512_shash_ops/sec
81712 -100.0% 0.00 stress-ng.af-alg.sm4_cipher_ops/sec
3919240 -100.0% 0.00 stress-ng.af-alg.stdrng_rng_ops/sec
217563 -100.0% 0.00 stress-ng.af-alg.twofish_cipher_ops/sec
197101 -100.0% 0.00 stress-ng.af-alg.wp256_shash_ops/sec
198136 -100.0% 0.00 stress-ng.af-alg.wp384_shash_ops/sec
198629 -100.0% 0.00 stress-ng.af-alg.wp512_shash_ops/sec
650714 -100.0% 0.00 stress-ng.af-alg.xchacha12_skcipher_ops/sec
591703 -100.0% 0.00 stress-ng.af-alg.xchacha20_skcipher_ops/sec
767692 -100.0% 0.00 stress-ng.af-alg.xctr_aes_skcipher_ops/sec
308770 -100.0% 0.00 stress-ng.af-alg.xts_camellia_skcipher_ops/sec
108533 -100.0% 0.00 stress-ng.af-alg.xts_cast6_skcipher_ops/sec
275830 -100.0% 0.00 stress-ng.af-alg.xts_serpent_skcipher_ops/sec
77237 -100.0% 0.00 stress-ng.af-alg.xts_sm4_skcipher_ops/sec
194950 -100.0% 0.00 stress-ng.af-alg.xts_twofish_skcipher_ops/sec
1563672 -100.0% 0.00 stress-ng.af-alg.xxhash64_shash_ops/sec
68461 +126.8% 155291 ± 4% stress-ng.time.involuntary_context_switches
55906 ± 3% -19.3% 45105 ± 7% stress-ng.time.minor_page_faults
22639 +11.3% 25205 stress-ng.time.percent_of_cpu_this_job_got
12857 +7.3% 13801 stress-ng.time.system_time
769.06 +76.6% 1357 stress-ng.time.user_time
122787 -96.3% 4579 ± 11% stress-ng.time.voluntary_context_switches
1.917e+09 ± 16% -64.2% 6.864e+08 ± 9% cpuidle..time
1480040 ± 2% -93.2% 100145 ± 10% cpuidle..usage
15.13 ± 8% -56.3% 6.62 vmstat.cpu.id
219.34 +9.8% 240.79 vmstat.procs.r
17547 ± 2% -63.5% 6412 ± 4% vmstat.system.cs
3.861e+08 +65.9% 6.405e+08 numa-numastat.node0.local_node
3.862e+08 +65.9% 6.407e+08 numa-numastat.node0.numa_hit
3.744e+08 +71.4% 6.417e+08 numa-numastat.node1.local_node
3.746e+08 +71.3% 6.418e+08 numa-numastat.node1.numa_hit
189.17 ± 11% -18.9% 153.33 ± 8% perf-c2c.DRAM.local
1905 ± 12% +20.5% 2297 ± 6% perf-c2c.DRAM.remote
3226 ± 13% +61.9% 5225 ± 5% perf-c2c.HITM.local
965.33 ± 13% +56.6% 1512 ± 7% perf-c2c.HITM.remote
4192 ± 13% +60.7% 6737 ± 5% perf-c2c.HITM.total
12.25 ± 12% -8.8 3.49 mpstat.cpu.all.idle%
0.71 ± 2% -0.2 0.49 ± 2% mpstat.cpu.all.irq%
0.17 +0.0 0.19 ± 2% mpstat.cpu.all.soft%
81.59 +5.5 87.06 mpstat.cpu.all.sys%
5.28 +3.5 8.77 mpstat.cpu.all.usr%
9.00 -55.6% 4.00 ± 20% mpstat.max_utilization.seconds
1.95e+08 ± 3% +198.7% 5.825e+08 ± 26% numa-vmstat.node0.nr_foll_pin_acquired
1.95e+08 ± 3% +198.7% 5.825e+08 ± 26% numa-vmstat.node0.nr_foll_pin_released
3.862e+08 +65.9% 6.407e+08 numa-vmstat.node0.numa_hit
3.861e+08 +65.9% 6.405e+08 numa-vmstat.node0.numa_local
1.9e+08 ± 5% +201.7% 5.732e+08 ± 30% numa-vmstat.node1.nr_foll_pin_acquired
1.9e+08 ± 5% +201.7% 5.732e+08 ± 30% numa-vmstat.node1.nr_foll_pin_released
3.746e+08 +71.3% 6.418e+08 numa-vmstat.node1.numa_hit
3.744e+08 +71.4% 6.417e+08 numa-vmstat.node1.numa_local
1411517 ± 3% -8.9% 1286468 meminfo.Active
1411517 ± 3% -8.9% 1286468 meminfo.Active(anon)
56168126 +6.8% 59960507 ± 3% meminfo.DirectMap1G
13462615 ± 7% -27.5% 9764268 ± 20% meminfo.DirectMap2M
387026 ± 3% -24.3% 292992 ± 6% meminfo.DirectMap4k
175544 +6.7% 187261 meminfo.KReclaimable
315400 ± 4% -17.9% 258792 ± 7% meminfo.Mapped
8955634 -5.5% 8462157 meminfo.Memused
175544 +6.7% 187261 meminfo.SReclaimable
646847 ± 6% -15.9% 543994 ± 2% meminfo.Shmem
19437 ± 2% -68.0% 6220 ± 4% perf-stat.i.context-switches
1657 -71.4% 474.53 perf-stat.i.cpu-migrations
49.18 ± 4% -97.0% 1.50 ± 13% perf-stat.i.major-faults
229800 ± 2% -93.4% 15108 ± 5% perf-stat.i.minor-faults
229849 ± 2% -93.4% 15109 ± 5% perf-stat.i.page-faults
17689 ± 2% -65.4% 6120 ± 4% perf-stat.ps.context-switches
1518 -69.3% 465.63 perf-stat.ps.cpu-migrations
44.10 ± 4% -96.8% 1.42 ± 13% perf-stat.ps.major-faults
206237 ± 2% -92.8% 14868 ± 5% perf-stat.ps.minor-faults
206281 ± 2% -92.8% 14869 ± 5% perf-stat.ps.page-faults
35935 ± 3% +12.9% 40575 ± 4% sched_debug.cfs_rq:/.avg_vruntime.avg
27019 ± 5% +19.2% 32216 ± 4% sched_debug.cfs_rq:/.avg_vruntime.min
28.22 ± 12% +74.0% 49.12 ± 42% sched_debug.cfs_rq:/.util_est.avg
35935 ± 3% +12.9% 40575 ± 4% sched_debug.cfs_rq:/.zero_vruntime.avg
27019 ± 5% +19.2% 32216 ± 4% sched_debug.cfs_rq:/.zero_vruntime.min
328465 ± 40% -62.5% 123124 ± 43% sched_debug.cpu.avg_idle.min
47.33 ± 17% -39.6% 28.58 ± 13% sched_debug.cpu.clock.stddev
5757 -8.8% 5250 ± 2% sched_debug.cpu.curr->pid.avg
35667 -67.3% 11660 sched_debug.cpu.curr->pid.max
4038 +11.7% 4509 ± 10% sched_debug.cpu.curr->pid.min
2546 ± 14% -64.2% 910.96 ± 8% sched_debug.cpu.curr->pid.stddev
0.00 ± 12% -36.2% 0.00 ± 15% sched_debug.cpu.next_balance.stddev
3715 ± 2% -35.4% 2400 ± 9% sched_debug.cpu.nr_switches.avg
2104 ± 6% -55.4% 938.83 ± 16% sched_debug.cpu.nr_switches.min
352445 ± 3% -8.7% 321795 proc-vmstat.nr_active_anon
192458 -3.0% 186632 proc-vmstat.nr_anon_pages
1186421 -2.1% 1161291 proc-vmstat.nr_file_pages
3.845e+08 ± 3% +200.2% 1.154e+09 ± 28% proc-vmstat.nr_foll_pin_acquired
3.845e+08 ± 3% +200.2% 1.154e+09 ± 28% proc-vmstat.nr_foll_pin_released
50743 -2.6% 49426 proc-vmstat.nr_kernel_stack
78630 ± 4% -17.6% 64812 ± 7% proc-vmstat.nr_mapped
161287 ± 6% -15.6% 136166 ± 2% proc-vmstat.nr_shmem
43884 +6.7% 46816 proc-vmstat.nr_slab_reclaimable
131569 -1.8% 129253 proc-vmstat.nr_slab_unreclaimable
352445 ± 3% -8.7% 321795 proc-vmstat.nr_zone_active_anon
7.608e+08 +68.6% 1.282e+09 proc-vmstat.numa_hit
7.605e+08 +68.6% 1.282e+09 proc-vmstat.numa_local
3520 ± 9% -22.5% 2727 ± 9% proc-vmstat.numa_pages_migrated
7.608e+08 +68.5% 1.282e+09 proc-vmstat.pgalloc_normal
12990982 -91.9% 1046211 ± 4% proc-vmstat.pgfault
7.6e+08 +68.6% 1.282e+09 proc-vmstat.pgfree
3520 ± 9% -22.5% 2727 ± 9% proc-vmstat.pgmigrate_success
37787 +4.1% 39342 proc-vmstat.pgreuse
0.38 ± 18% +53.1% 0.59 ± 16% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
0.31 ± 16% -77.6% 0.07 ± 32% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.13 ± 12% -80.7% 0.02 ± 17% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
0.07 ± 31% -80.2% 0.01 ± 35% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.74 ± 52% -100.0% 0.00 ±223% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].[unknown]
0.13 ± 56% -84.2% 0.02 ± 27% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].stress_af_alg
0.15 ± 18% -82.6% 0.03 ± 26% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
0.03 ± 53% -67.2% 0.01 ± 69% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_call_function_single.[unknown].stress_af_alg
0.04 ± 47% -65.3% 0.01 ± 38% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_call_function_single.stress_rndbuf.stress_af_alg
0.22 ±121% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__blowfish_dec_blk_4way
0.27 ± 43% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__serpent_encrypt
0.16 ± 73% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
0.04 ± 71% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_get_nstime
0.16 ± 65% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
0.12 ± 55% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
0.19 ± 15% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
0.20 ± 75% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
0.16 ± 6% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
0.25 ± 87% -72.7% 0.07 ±150% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt._skcipher_recvmsg
0.80 ±130% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
0.53 ± 49% -89.6% 0.05 ±114% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt._skcipher_recvmsg
0.39 ± 63% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
0.36 ± 6% -84.5% 0.06 ± 12% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.affine_move_task.__set_cpus_allowed_ptr.__sched_setaffinity
0.01 ±223% +4091.7% 0.34 ±102% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.kfree.sock_kfree_s.af_alg_free_resources
0.30 ± 14% -93.2% 0.02 ± 15% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.schedule_timeout.kcompactd.kthread.ret_from_fork
0.24 ± 7% -90.0% 0.02 ± 5% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.schedule_timeout.rcu_gp_fqs_loop.rcu_gp_kthread.kthread
0.78 ± 9% -39.6% 0.47 ± 10% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.wait_for_partner.fifo_open.do_dentry_open.vfs_open
0.32 ± 3% -90.8% 0.03 ± 7% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.worker_thread.kthread.ret_from_fork.ret_from_fork_asm
14.84 ± 23% -77.4% 3.36 ± 10% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
2.49 ± 18% -42.0% 1.45 ± 65% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
1.09 ± 77% -100.0% 0.00 ±223% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].[unknown]
0.01 ±141% +108.7% 0.02 ± 79% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.bind.stress_af_alg
0.52 ±126% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__blowfish_dec_blk_4way
2.14 ± 44% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__serpent_encrypt
1.50 ± 64% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
0.49 ±183% +312.3% 2.01 ± 46% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.crypto_ecb_decrypt2
1.21 ± 13% -54.4% 0.55 ± 67% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.fold_vm_zone_numa_events
0.07 ± 67% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_get_nstime
1.95 ± 43% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
1.57 ± 74% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
3.69 ± 12% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
2.12 ± 68% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
4.71 ± 29% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
1.36 ± 86% -85.2% 0.20 ±151% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt._skcipher_recvmsg
1.70 ± 76% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
2.43 ± 33% -91.0% 0.22 ±157% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt._skcipher_recvmsg
1.82 ± 54% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
0.01 ±223% +7690.0% 0.78 ±131% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.kfree.sock_kfree_s.af_alg_free_resources
1.01 -94.6% 0.05 ± 25% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.schedule_timeout.kcompactd.kthread.ret_from_fork
0.25 ± 11% -80.7% 0.05 ± 19% perf-sched.total_sch_delay.average.ms
166.36 ± 2% -35.2% 107.80 ± 9% perf-sched.total_wait_and_delay.average.ms
13558 ± 2% +143.0% 32951 ± 9% perf-sched.total_wait_and_delay.count.ms
166.11 ± 2% -35.1% 107.75 ± 9% perf-sched.total_wait_time.average.ms
41.96 ± 23% +86.9% 78.40 ± 7% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
10.39 ± 96% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
1.64 ± 7% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
2.05 ± 36% -80.0% 0.41 ± 23% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
0.14 ± 30% -80.4% 0.03 ± 35% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.30 ± 18% -82.7% 0.05 ± 26% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
0.39 ± 15% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
0.33 ± 6% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
380.25 ± 9% +27.8% 485.92 ± 3% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0
3.21 ± 7% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
586.14 -66.7% 195.29 ± 11% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
1007 ± 24% -47.3% 531.33 ± 7% perf-sched.wait_and_delay.count.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
124.00 -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
105.17 ± 3% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
3807 ± 4% +235.5% 12773 ± 9% perf-sched.wait_and_delay.count.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
149.33 ± 3% +368.2% 699.17 ± 16% perf-sched.wait_and_delay.count.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
202.17 ± 3% +432.0% 1075 ± 14% perf-sched.wait_and_delay.count.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
211.83 ± 6% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
1048 ± 4% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
32.17 ± 9% -22.8% 24.83 ± 3% perf-sched.wait_and_delay.count.perf_trace_sched_switch.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0
1083 -7.7% 1000 ± 2% perf-sched.wait_and_delay.count.perf_trace_sched_switch.schedule_timeout.rcu_gp_fqs_loop.rcu_gp_kthread.kthread
87.00 -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
1866 +554.9% 12223 ± 12% perf-sched.wait_and_delay.count.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
1135 -9.6% 1027 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
1021 ±115% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
6.91 ± 22% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.98 ± 18% -42.0% 2.89 ± 65% perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
7.39 ± 12% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
9.42 ± 29% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
43.37 ± 67% -77.1% 9.94 ± 29% perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.schedule_timeout.rcu_gp_fqs_loop.rcu_gp_kthread.kthread
8.56 ± 4% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
3458 ± 27% -51.5% 1678 ± 30% perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
41.84 ± 23% +87.1% 78.28 ± 7% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
1.33 ± 6% -46.6% 0.71 ± 4% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.93 ± 39% -79.9% 0.39 ± 25% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
0.07 ± 31% -80.2% 0.01 ± 35% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.13 ± 56% -84.2% 0.02 ± 27% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].stress_af_alg
0.15 ± 18% -82.6% 0.03 ± 26% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
0.03 ± 53% -67.2% 0.01 ± 69% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_call_function_single.[unknown].stress_af_alg
0.04 ± 47% -65.3% 0.01 ± 38% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_call_function_single.stress_rndbuf.stress_af_alg
0.22 ±121% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__blowfish_dec_blk_4way
0.27 ± 43% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__serpent_encrypt
0.16 ± 73% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
0.04 ± 71% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_get_nstime
0.16 ± 65% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
0.12 ± 55% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
0.19 ± 15% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
0.20 ± 75% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
0.16 ± 6% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
0.25 ± 87% -72.7% 0.07 ±150% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt._skcipher_recvmsg
0.80 ±130% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
0.53 ± 49% -89.6% 0.05 ±114% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt._skcipher_recvmsg
0.39 ± 63% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
0.01 ±223% +4091.7% 0.34 ±102% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.kfree.sock_kfree_s.af_alg_free_resources
378.01 ± 9% +28.2% 484.79 ± 3% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0
4.64 +8.5% 5.04 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.schedule_timeout.rcu_gp_fqs_loop.rcu_gp_kthread.kthread
586.12 -66.7% 195.27 ± 11% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
1134 -9.5% 1027 perf-sched.wait_time.max.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
2.49 ± 18% -42.0% 1.45 ± 65% perf-sched.wait_time.max.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.01 ±141% +108.7% 0.02 ± 79% perf-sched.wait_time.max.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.bind.stress_af_alg
0.52 ±126% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__blowfish_dec_blk_4way
2.14 ± 44% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__serpent_encrypt
1.50 ± 64% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
0.49 ±183% +312.3% 2.01 ± 46% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.crypto_ecb_decrypt2
0.07 ± 67% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_get_nstime
1.95 ± 43% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
1.57 ± 74% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
3.69 ± 12% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
2.12 ± 68% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
4.71 ± 29% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
1.36 ± 86% -85.2% 0.20 ±151% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt._skcipher_recvmsg
1.70 ± 76% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
2.43 ± 33% -91.0% 0.22 ±157% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt._skcipher_recvmsg
1.82 ± 54% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
0.01 ±223% +7690.0% 0.78 ±131% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.kfree.sock_kfree_s.af_alg_free_resources
30.48 ± 42% -72.7% 8.31 ± 22% perf-sched.wait_time.max.ms.perf_trace_sched_switch.schedule_timeout.rcu_gp_fqs_loop.rcu_gp_kthread.kthread
8.14 ± 6% -23.1% 6.26 ± 9% perf-sched.wait_time.max.ms.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
3458 ± 27% -51.5% 1678 ± 30% perf-sched.wait_time.max.ms.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
***************************************************************************************************
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
gcc-14/performance/x86_64-rhel-9.4/100%/debian-13-x86_64-20250902.cgz/lkp-srf-2sp1/af-alg/stress-ng/60s
commit:
7e28b0a5c4 ("crypto: qce - Remove unsafe/deprecated algorithms")
2f204fe718 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
7e28b0a5c4b7d075 2f204fe718f5bf519013cc2536a
---------------- ---------------------------
%stddev %change %stddev
\ | \
216855 -100.0% 0.00 stress-ng.af-alg.blowfish_cipher_ops/sec
209524 ± 6% -100.0% 0.00 stress-ng.af-alg.camellia_cipher_ops/sec
190546 ± 4% -100.0% 0.00 stress-ng.af-alg.cast5_cipher_ops/sec
135294 ± 3% -100.0% 0.00 stress-ng.af-alg.cast6_cipher_ops/sec
479356 -4.0% 460371 stress-ng.af-alg.cbc_aes_skcipher_ops/sec
217326 -100.0% 0.00 stress-ng.af-alg.cbc_blowfish_skcipher_ops/sec
207506 ± 6% -100.0% 0.00 stress-ng.af-alg.cbc_camellia_skcipher_ops/sec
193783 ± 4% -100.0% 0.00 stress-ng.af-alg.cbc_cast5_skcipher_ops/sec
137997 ± 3% -100.0% 0.00 stress-ng.af-alg.cbc_cast6_skcipher_ops/sec
59293 -13.2% 51441 stress-ng.af-alg.cbc_des_skcipher_ops/sec
184573 ± 7% -100.0% 0.00 stress-ng.af-alg.cbc_serpent_skcipher_ops/sec
65374 -100.0% 0.00 stress-ng.af-alg.cbc_sm4_skcipher_ops/sec
224719 ± 2% -100.0% 0.00 stress-ng.af-alg.cbc_twofish_skcipher_ops/sec
378937 ± 3% -100.0% 0.00 stress-ng.af-alg.chacha20_skcipher_ops/sec
701429 ± 3% -100.0% 0.00 stress-ng.af-alg.cipher_null_cipher_ops/sec
805125 ± 2% -100.0% 0.00 stress-ng.af-alg.crc32_shash_ops/sec
1012208 ± 2% -100.0% 0.00 stress-ng.af-alg.crc32c_shash_ops/sec
88666 -100.0% 0.00 stress-ng.af-alg.ctr_blowfish_skcipher_ops/sec
103288 -100.0% 0.00 stress-ng.af-alg.ctr_camellia_skcipher_ops/sec
96558 -100.0% 0.00 stress-ng.af-alg.ctr_cast5_skcipher_ops/sec
83138 -100.0% 0.00 stress-ng.af-alg.ctr_cast6_skcipher_ops/sec
24949 -100.0% 0.00 stress-ng.af-alg.ctr_des3_ede_skcipher_ops/sec
64739 -100.0% 0.00 stress-ng.af-alg.ctr_des_skcipher_ops/sec
63942 -100.0% 0.00 stress-ng.af-alg.ctr_serpent_skcipher_ops/sec
69264 -100.0% 0.00 stress-ng.af-alg.ctr_sm4_skcipher_ops/sec
136885 -100.0% 0.00 stress-ng.af-alg.ctr_twofish_skcipher_ops/sec
457005 -100.0% 0.00 stress-ng.af-alg.cts_cbc_aes_skcipher_ops/sec
64293 -100.0% 0.00 stress-ng.af-alg.cts_cbc_sm4_skcipher_ops/sec
25458 -100.0% 0.00 stress-ng.af-alg.des3_ede_cipher_ops/sec
216965 -100.0% 0.00 stress-ng.af-alg.ecb_blowfish_skcipher_ops/sec
209313 ± 6% -100.0% 0.00 stress-ng.af-alg.ecb_camellia_skcipher_ops/sec
190769 ± 4% -100.0% 0.00 stress-ng.af-alg.ecb_cast5_skcipher_ops/sec
135248 ± 3% -100.0% 0.00 stress-ng.af-alg.ecb_cast6_skcipher_ops/sec
702104 ± 3% -100.0% 0.00 stress-ng.af-alg.ecb_cipher_null_skcipher_ops/sec
25448 -100.0% 0.00 stress-ng.af-alg.ecb_des3_ede_skcipher_ops/sec
182596 ± 7% -100.0% 0.00 stress-ng.af-alg.ecb_serpent_skcipher_ops/sec
70347 -100.0% 0.00 stress-ng.af-alg.ecb_sm4_skcipher_ops/sec
219007 ± 2% -100.0% 0.00 stress-ng.af-alg.ecb_twofish_skcipher_ops/sec
457398 -100.0% 0.00 stress-ng.af-alg.gcm_aes_aead_ops/sec
62426 -100.0% 0.00 stress-ng.af-alg.gcm_sm4_aead_ops/sec
553.77 -100.0% 0.00 stress-ng.af-alg.jitterentropy_rng_rng_ops/sec
397336 -100.0% 0.00 stress-ng.af-alg.lrw_aes_skcipher_ops/sec
193284 ± 6% -100.0% 0.00 stress-ng.af-alg.lrw_camellia_skcipher_ops/sec
128008 ± 3% -100.0% 0.00 stress-ng.af-alg.lrw_cast6_skcipher_ops/sec
170053 ± 7% -100.0% 0.00 stress-ng.af-alg.lrw_serpent_skcipher_ops/sec
200877 ± 2% -100.0% 0.00 stress-ng.af-alg.lrw_twofish_skcipher_ops/sec
684836 ± 3% -8.8% 624898 ± 2% stress-ng.af-alg.md4_shash_ops/sec
4.649e+08 +94.3% 9.035e+08 stress-ng.af-alg.ops
7731460 +94.8% 15059678 stress-ng.af-alg.ops_per_sec
482644 -100.0% 0.00 stress-ng.af-alg.rfc3686_ctr_aes_skcipher_ops/sec
277551 -100.0% 0.00 stress-ng.af-alg.rmd160_shash_ops/sec
183019 ± 7% -100.0% 0.00 stress-ng.af-alg.serpent_cipher_ops/sec
242936 -100.0% 0.00 stress-ng.af-alg.sha3-384_shash_ops/sec
183762 -100.0% 0.00 stress-ng.af-alg.sha3-512_shash_ops/sec
70335 -100.0% 0.00 stress-ng.af-alg.sm4_cipher_ops/sec
3962546 -100.0% 0.00 stress-ng.af-alg.stdrng_rng_ops/sec
219095 ± 2% -100.0% 0.00 stress-ng.af-alg.twofish_cipher_ops/sec
230665 -100.0% 0.00 stress-ng.af-alg.wp256_shash_ops/sec
231679 -100.0% 0.00 stress-ng.af-alg.wp384_shash_ops/sec
232469 -100.0% 0.00 stress-ng.af-alg.wp512_shash_ops/sec
410669 ± 3% -100.0% 0.00 stress-ng.af-alg.xchacha12_skcipher_ops/sec
360829 ± 3% -100.0% 0.00 stress-ng.af-alg.xchacha20_skcipher_ops/sec
491724 -100.0% 0.00 stress-ng.af-alg.xctr_aes_skcipher_ops/sec
167510 ± 5% -100.0% 0.00 stress-ng.af-alg.xts_camellia_skcipher_ops/sec
117726 ± 3% -100.0% 0.00 stress-ng.af-alg.xts_cast6_skcipher_ops/sec
150916 ± 6% -100.0% 0.00 stress-ng.af-alg.xts_serpent_skcipher_ops/sec
65448 -100.0% 0.00 stress-ng.af-alg.xts_sm4_skcipher_ops/sec
177065 ± 2% -100.0% 0.00 stress-ng.af-alg.xts_twofish_skcipher_ops/sec
1276683 ± 5% -100.0% 0.00 stress-ng.af-alg.xxhash64_shash_ops/sec
76318 ± 3% +204.7% 232555 ± 7% stress-ng.time.involuntary_context_switches
91019 -35.6% 58616 ± 6% stress-ng.time.minor_page_faults
23417 +7.6% 25203 stress-ng.time.percent_of_cpu_this_job_got
13227 +3.7% 13723 stress-ng.time.system_time
916.14 +59.1% 1457 stress-ng.time.user_time
120751 -96.3% 4444 ± 8% stress-ng.time.voluntary_context_switches
1708577 ± 3% -87.9% 206193 ± 13% cpuidle..usage
0.06 ± 3% +0.0 0.08 mpstat.cpu.all.soft%
6.27 +2.8 9.03 ± 4% mpstat.cpu.all.usr%
60031341 ± 2% +3.5% 62149354 ± 2% numa-meminfo.node0.MemFree
5669438 ± 23% -37.4% 3551425 ± 50% numa-meminfo.node0.MemUsed
487.50 ± 5% -23.6% 372.50 ± 13% perf-c2c.DRAM.remote
297.17 ± 7% -12.7% 259.33 ± 11% perf-c2c.HITM.remote
18714 -55.2% 8375 ± 4% vmstat.system.cs
651936 -7.9% 600609 ± 4% vmstat.system.in
3.811e+08 +53.3% 5.842e+08 numa-numastat.node0.local_node
3.812e+08 +53.3% 5.844e+08 numa-numastat.node0.numa_hit
3.795e+08 +53.2% 5.812e+08 numa-numastat.node1.local_node
3.796e+08 +53.1% 5.813e+08 numa-numastat.node1.numa_hit
2.252e+08 ± 28% +123.8% 5.041e+08 ± 35% numa-vmstat.node0.nr_foll_pin_acquired
2.252e+08 ± 28% +123.8% 5.041e+08 ± 35% numa-vmstat.node0.nr_foll_pin_released
15007558 ± 2% +3.5% 15536798 ± 2% numa-vmstat.node0.nr_free_pages
3.812e+08 +53.3% 5.844e+08 numa-vmstat.node0.numa_hit
3.811e+08 +53.3% 5.842e+08 numa-vmstat.node0.numa_local
2.313e+08 ± 30% +118.9% 5.062e+08 ± 32% numa-vmstat.node1.nr_foll_pin_acquired
2.313e+08 ± 30% +118.9% 5.062e+08 ± 32% numa-vmstat.node1.nr_foll_pin_released
3.796e+08 +53.1% 5.813e+08 numa-vmstat.node1.numa_hit
3.795e+08 +53.2% 5.812e+08 numa-vmstat.node1.numa_local
6024 ± 7% -13.3% 5222 ± 4% sched_debug.cfs_rq:/.avg_vruntime.stddev
28.15 ± 5% +108.4% 58.64 ± 23% sched_debug.cfs_rq:/.util_est.avg
6024 ± 7% -13.3% 5222 ± 4% sched_debug.cfs_rq:/.zero_vruntime.stddev
5785 ± 2% -7.6% 5347 sched_debug.cpu.curr->pid.avg
36539 -67.8% 11768 sched_debug.cpu.curr->pid.max
2446 ± 2% -57.9% 1030 ± 3% sched_debug.cpu.curr->pid.stddev
3548 ± 2% -37.0% 2236 ± 4% sched_debug.cpu.nr_switches.avg
18448 ± 6% -11.1% 16403 ± 4% sched_debug.cpu.nr_switches.max
2190 ± 3% -52.0% 1050 ± 16% sched_debug.cpu.nr_switches.min
0.01 -0.0 0.00 turbostat.C1%
3.54 -3.3 0.28 ± 5% turbostat.C1E%
2.25 ± 2% -2.0 0.26 ± 9% turbostat.C6S%
3.56 -92.0% 0.28 ± 5% turbostat.CPU%c1
2.87 -25.9% 2.13 turbostat.IPC
9876648 -8.0% 9090571 turbostat.NMI
0.00 ±223% +26800.0% 0.45 ± 61% turbostat.Pkg%pc2
55.33 ± 11% -16.0% 46.50 ± 2% turbostat.PkgTmp
435.70 -13.7% 376.19 ± 2% turbostat.PkgWatt
1868796 -6.8% 1742616 ± 2% meminfo.Active
1868796 -6.8% 1742616 ± 2% meminfo.Active(anon)
13873747 ± 6% -22.3% 10778257 ± 13% meminfo.DirectMap2M
371335 ± 2% -24.2% 281423 ± 5% meminfo.DirectMap4k
180632 +6.1% 191567 meminfo.KReclaimable
406906 ± 6% -16.5% 339717 ± 7% meminfo.Mapped
9491571 -4.9% 9030449 meminfo.Memused
36225 -12.0% 31879 ± 2% meminfo.PageTables
180632 +6.1% 191567 meminfo.SReclaimable
1090073 -9.9% 982056 ± 5% meminfo.Shmem
22727 -62.4% 8551 ± 5% perf-stat.i.context-switches
2333 -80.7% 449.78 ± 2% perf-stat.i.cpu-migrations
175.57 ± 3% -97.4% 4.63 ± 7% perf-stat.i.major-faults
267773 -93.7% 16776 ± 4% perf-stat.i.minor-faults
267949 -93.7% 16780 ± 4% perf-stat.i.page-faults
19001 -56.8% 8200 ± 5% perf-stat.ps.context-switches
1952 -78.8% 414.65 ± 2% perf-stat.ps.cpu-migrations
142.75 ± 3% -97.3% 3.81 ± 9% perf-stat.ps.major-faults
218341 -93.3% 14704 ± 4% perf-stat.ps.minor-faults
218484 -93.3% 14708 ± 4% perf-stat.ps.page-faults
467477 -6.8% 435805 ± 3% proc-vmstat.nr_active_anon
195424 -2.4% 190648 proc-vmstat.nr_anon_pages
1297860 -2.1% 1270763 proc-vmstat.nr_file_pages
4.573e+08 ± 29% +121.4% 1.012e+09 ± 33% proc-vmstat.nr_foll_pin_acquired
4.573e+08 ± 29% +121.4% 1.012e+09 ± 33% proc-vmstat.nr_foll_pin_released
53202 -4.1% 51028 proc-vmstat.nr_kernel_stack
101975 ± 6% -16.8% 84803 ± 8% proc-vmstat.nr_mapped
9052 -12.0% 7969 ± 2% proc-vmstat.nr_page_table_pages
272763 -9.9% 245676 ± 5% proc-vmstat.nr_shmem
45164 +6.1% 47897 proc-vmstat.nr_slab_reclaimable
125864 -2.4% 122785 proc-vmstat.nr_slab_unreclaimable
467477 -6.8% 435805 ± 3% proc-vmstat.nr_zone_active_anon
7.609e+08 +53.2% 1.166e+09 proc-vmstat.numa_hit
7.606e+08 +53.2% 1.165e+09 proc-vmstat.numa_local
7.609e+08 +53.2% 1.166e+09 proc-vmstat.pgalloc_normal
13568843 -92.1% 1074388 ± 2% proc-vmstat.pgfault
7.599e+08 +53.3% 1.165e+09 proc-vmstat.pgfree
25.00 ± 29% -56.0% 11.00 ± 53% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.devkmsg_read.vfs_read.ksys_read.do_syscall_64
0.74 ±112% -97.8% 0.02 ± 15% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.do_nanosleep.hrtimer_nanosleep.common_nsleep.__x64_sys_clock_nanosleep
0.39 ± 14% +102.6% 0.79 ± 15% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
0.30 ± 7% -39.9% 0.18 ± 22% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.13 ± 10% -82.4% 0.02 ± 32% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
0.05 ± 59% -72.9% 0.01 ± 17% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.08 ± 65% -88.6% 0.01 ± 45% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.setsockopt
0.13 ± 51% -86.9% 0.02 ± 41% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].stress_af_alg
0.12 ± 33% -81.5% 0.02 ± 44% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
0.00 ±223% +820.0% 0.01 ± 57% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_time_now.stress_af_alg
0.30 ± 55% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__cast5_encrypt
0.12 ± 46% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
0.00 ±141% +7715.0% 0.26 ±116% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.af_alg_pull_tsgl
8.59 ± 38% -71.3% 2.46 ±102% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.copy_folio_from_iter_atomic
0.01 ±174% +2979.6% 0.25 ± 58% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.crypto_ecb_encrypt2
0.10 ± 61% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
0.12 ± 68% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
0.12 ± 33% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
0.11 ± 51% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
0.13 ± 14% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
0.25 ±102% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.xts_xor_tweak
0.00 ±223% +14966.7% 0.15 ±143% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.cbc_encrypt._skcipher_recvmsg
0.34 ±102% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.chacha_crypt.chacha_stream_xor
0.32 ± 99% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
0.37 ±139% -100.0% 0.00 perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
0.33 ± 16% -77.3% 0.07 ± 30% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.affine_move_task.__set_cpus_allowed_ptr.__sched_setaffinity
1.09 ± 9% -85.3% 0.16 ±184% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.schedule_hrtimeout_range_clock.ep_poll.do_epoll_wait.__x64_sys_epoll_wait
0.29 ± 48% -93.0% 0.02 ± 6% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.schedule_timeout.kcompactd.kthread.ret_from_fork
0.16 ± 20% -85.2% 0.02 ± 5% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.schedule_timeout.rcu_gp_fqs_loop.rcu_gp_kthread.kthread
0.78 ± 12% -25.8% 0.58 ± 11% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.wait_for_partner.fifo_open.do_dentry_open.vfs_open
0.31 ± 4% -90.8% 0.03 ± 5% perf-sched.sch_delay.avg.ms.perf_trace_sched_switch.worker_thread.kthread.ret_from_fork.ret_from_fork_asm
12.84 ± 33% -59.6% 5.19 ± 34% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
49.68 ± 30% -55.8% 21.97 ± 53% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.devkmsg_read.vfs_read.ksys_read.do_syscall_64
3.14 ±142% -99.1% 0.03 ± 14% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.do_nanosleep.hrtimer_nanosleep.common_nsleep.__x64_sys_clock_nanosleep
1.05 ± 87% -96.2% 0.04 ± 83% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.setsockopt
0.00 ±223% +2220.0% 0.02 ± 93% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_time_now.stress_af_alg
1.54 ± 58% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__cast5_encrypt
1.53 ± 59% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
6.62 ±119% -73.7% 1.74 ± 48% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt._raw_spin_unlock_irqrestore
0.00 ±141% +17850.0% 0.60 ±102% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.af_alg_pull_tsgl
69.63 ± 40% -81.6% 12.82 ±145% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.copy_folio_from_iter_atomic
0.01 ±174% +21434.7% 1.76 ± 41% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.crypto_ecb_encrypt2
1.67 ± 67% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
1.73 ± 79% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
3.59 ± 53% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
2.15 ± 49% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
4.86 ± 42% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
0.65 ± 95% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.xts_xor_tweak
0.00 ±223% +39633.3% 0.40 ±133% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.cbc_encrypt._skcipher_recvmsg
0.63 ± 77% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.chacha_crypt.chacha_stream_xor
1.00 ± 98% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
1.79 ±150% -100.0% 0.00 perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
41.71 ±121% -89.5% 4.40 ± 98% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.affine_move_task.__set_cpus_allowed_ptr.__sched_setaffinity
12.21 ± 5% -84.7% 1.86 ±207% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.schedule_hrtimeout_range_clock.ep_poll.do_epoll_wait.__x64_sys_epoll_wait
0.97 ± 6% -95.1% 0.05 ± 11% perf-sched.sch_delay.max.ms.perf_trace_sched_switch.schedule_timeout.kcompactd.kthread.ret_from_fork
0.22 ± 16% -77.5% 0.05 ± 45% perf-sched.total_sch_delay.average.ms
183.40 ± 3% -42.9% 104.76 ± 10% perf-sched.total_wait_and_delay.average.ms
13126 ± 2% +170.9% 35557 ± 10% perf-sched.total_wait_and_delay.count.ms
4251 ± 4% +15.1% 4894 perf-sched.total_wait_and_delay.max.ms
183.18 ± 3% -42.8% 104.71 ± 10% perf-sched.total_wait_time.average.ms
4251 ± 4% +15.1% 4894 perf-sched.total_wait_time.max.ms
56.31 ± 18% +76.8% 99.58 ± 17% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
454.97 ± 4% +26.2% 574.25 ± 9% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.anon_pipe_read.vfs_read.ksys_read.do_syscall_64
0.78 ± 14% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
1.63 ± 3% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.51 ± 27% -76.8% 0.35 ± 58% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
0.09 ± 59% -73.2% 0.02 ± 19% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.26 ± 51% -86.9% 0.03 ± 42% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].stress_af_alg
0.25 ± 33% -81.5% 0.05 ± 44% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
0.25 ± 33% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
0.27 ± 14% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
2.74 ± 5% -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
590.52 ± 2% -68.5% 186.05 ± 14% perf-sched.wait_and_delay.avg.ms.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
743.00 ± 18% -45.7% 403.67 ± 21% perf-sched.wait_and_delay.count.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
61.00 ± 6% -23.2% 46.83 ± 8% perf-sched.wait_and_delay.count.perf_trace_sched_switch.anon_pipe_read.vfs_read.ksys_read.do_syscall_64
120.67 ± 4% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
103.67 ± 2% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
3679 ± 4% +282.5% 14076 ± 11% perf-sched.wait_and_delay.count.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
97.50 ± 10% +218.3% 310.33 ± 23% perf-sched.wait_and_delay.count.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
80.67 ± 10% +509.9% 492.00 ± 11% perf-sched.wait_and_delay.count.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].stress_af_alg
178.00 ± 6% +537.5% 1134 ± 13% perf-sched.wait_and_delay.count.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
231.67 ± 3% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
828.83 ± 3% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
85.17 ± 3% -100.0% 0.00 perf-sched.wait_and_delay.count.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
2074 ± 2% +557.6% 13639 ± 14% perf-sched.wait_and_delay.count.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
1115 -7.3% 1034 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
7.50 -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
5.56 ± 20% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
7.18 ± 53% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
9.71 ± 42% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
7.75 ± 3% -100.0% 0.00 perf-sched.wait_and_delay.max.ms.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
64.72 ±141% +105.5% 132.96 ± 70% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.__x64_sys_pause.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
56.19 ± 18% +76.9% 99.39 ± 17% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
451.19 ± 4% +26.4% 570.38 ± 9% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.anon_pipe_read.vfs_read.ksys_read.do_syscall_64
0.39 ± 14% +462.3% 2.19 ±139% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group
1.33 ± 2% -15.4% 1.13 ± 3% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.do_wait.kernel_wait4.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.38 ± 29% -76.3% 0.33 ± 61% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
0.05 ± 59% -72.9% 0.01 ± 17% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.08 ± 65% -88.6% 0.01 ± 45% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.setsockopt
0.13 ± 51% -86.9% 0.02 ± 41% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.[unknown].stress_af_alg
0.12 ± 33% -81.5% 0.02 ± 44% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_rndbuf.stress_af_alg
0.00 ±223% +820.0% 0.01 ± 57% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_time_now.stress_af_alg
0.30 ± 55% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__cast5_encrypt
0.12 ± 46% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
0.00 ±141% +7715.0% 0.26 ±116% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.af_alg_pull_tsgl
0.01 ±174% +2979.6% 0.25 ± 58% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.crypto_ecb_encrypt2
0.10 ± 61% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
0.12 ± 68% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
0.12 ± 33% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
0.11 ± 51% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
0.13 ± 14% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
0.25 ±102% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.xts_xor_tweak
0.00 ±223% +14966.7% 0.15 ±143% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.cbc_encrypt._skcipher_recvmsg
0.34 ±102% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.chacha_crypt.chacha_stream_xor
0.32 ± 99% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
0.37 ±139% -100.0% 0.00 perf-sched.wait_time.avg.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
2.49 ± 4% +11.3% 2.77 ± 2% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.schedule_timeout.wait_for_completion_state.kernel_clone.__x64_sys_vfork
590.50 ± 2% -68.5% 186.03 ± 14% perf-sched.wait_time.avg.ms.perf_trace_sched_switch.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
323.08 ±141% +105.8% 664.78 ± 70% perf-sched.wait_time.max.ms.perf_trace_sched_switch.__x64_sys_pause.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown]
1114 -7.3% 1033 perf-sched.wait_time.max.ms.perf_trace_sched_switch.anon_pipe_read.fifo_pipe_read.vfs_read.ksys_read
1.05 ± 87% -96.2% 0.04 ± 83% perf-sched.wait_time.max.ms.perf_trace_sched_switch.exit_to_user_mode_loop.do_syscall_64.entry_SYSCALL_64_after_hwframe.setsockopt
0.00 ±223% +2220.0% 0.02 ± 93% perf-sched.wait_time.max.ms.perf_trace_sched_switch.irqentry_exit.asm_sysvec_apic_timer_interrupt.stress_time_now.stress_af_alg
1.54 ± 58% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__cast5_encrypt
1.53 ± 59% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.__sha3_update
6.62 ±119% -77.8% 1.47 ± 79% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt._raw_spin_unlock_irqrestore
0.00 ±141% +17850.0% 0.60 ±102% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.af_alg_pull_tsgl
0.01 ±174% +21434.7% 1.76 ± 41% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.crypto_ecb_encrypt2
1.67 ± 67% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_hash_time
1.73 ± 79% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_loop_shuffle
3.59 ± 53% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.jent_memaccess
2.15 ± 49% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_final
4.86 ± 42% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.sha3_keccakf_one_round_generic
0.65 ± 95% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_irq.irqentry_exit.asm_sysvec_apic_timer_interrupt.xts_xor_tweak
0.00 ±223% +39633.3% 0.40 ±133% perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.cbc_encrypt._skcipher_recvmsg
0.63 ± 77% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.chacha_crypt.chacha_stream_xor
1.00 ± 98% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_decrypt.xts_decrypt
1.79 ±150% -100.0% 0.00 perf-sched.wait_time.max.ms.perf_trace_sched_switch.preempt_schedule_thunk.__local_bh_enable_ip.ecb_encrypt.xts_encrypt
43.79 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_run
43.79 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.stress_run
43.78 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_run
43.78 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_run
43.78 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp._rng_recvmsg.sock_recvmsg.sock_read_iter.vfs_read.ksys_read
43.77 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.jent_kcapi_random._rng_recvmsg.sock_recvmsg.sock_read_iter.vfs_read
43.77 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.jent_read_entropy.jent_kcapi_random._rng_recvmsg.sock_recvmsg.sock_read_iter
43.76 ± 10% -43.8 0.00 perf-profile.calltrace.cycles-pp.jent_gen_entropy.jent_read_entropy.jent_kcapi_random._rng_recvmsg.sock_recvmsg
43.72 ± 10% -43.7 0.00 perf-profile.calltrace.cycles-pp.jent_measure_jitter.jent_gen_entropy.jent_read_entropy.jent_kcapi_random._rng_recvmsg
34.52 ± 10% -34.5 0.00 perf-profile.calltrace.cycles-pp.jent_condition_data.jent_measure_jitter.jent_gen_entropy.jent_read_entropy.jent_kcapi_random
34.43 ± 10% -34.4 0.00 perf-profile.calltrace.cycles-pp.jent_hash_time.jent_condition_data.jent_measure_jitter.jent_gen_entropy.jent_read_entropy
32.96 ± 10% -33.0 0.00 perf-profile.calltrace.cycles-pp.sha3_final.jent_hash_time.jent_condition_data.jent_measure_jitter.jent_gen_entropy
30.36 ± 10% -30.4 0.00 perf-profile.calltrace.cycles-pp.sha3_keccakf_one_round_generic.sha3_final.jent_hash_time.jent_condition_data.jent_measure_jitter
63.01 ± 3% -24.0 39.06 perf-profile.calltrace.cycles-pp.sock_recvmsg.sock_read_iter.vfs_read.ksys_read.do_syscall_64
63.08 ± 3% -23.9 39.14 perf-profile.calltrace.cycles-pp.sock_read_iter.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe
9.06 ± 9% -9.1 0.00 perf-profile.calltrace.cycles-pp.jent_memaccess.jent_measure_jitter.jent_gen_entropy.jent_read_entropy.jent_kcapi_random
4.35 ± 22% -4.4 0.00 perf-profile.calltrace.cycles-pp.crypto_ctr_crypt._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg.__sys_recvfrom
4.35 ± 22% -4.3 0.00 perf-profile.calltrace.cycles-pp.crypto_ctr_crypt._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg.sock_read_iter
3.82 ± 10% -2.1 1.71 ± 16% perf-profile.calltrace.cycles-pp.alg_bind.__sys_bind.__x64_sys_bind.do_syscall_64.entry_SYSCALL_64_after_hwframe
3.84 ± 10% -2.1 1.74 ± 16% perf-profile.calltrace.cycles-pp.__sys_bind.__x64_sys_bind.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind
0.68 ± 10% +0.2 0.88 perf-profile.calltrace.cycles-pp.__pi_memset.sg_init_table.af_alg_sendmsg.____sys_sendmsg.___sys_sendmsg
0.70 ± 10% +0.2 0.91 perf-profile.calltrace.cycles-pp.sg_init_table.af_alg_sendmsg.____sys_sendmsg.___sys_sendmsg.__sys_sendmsg
0.65 ± 10% +0.4 1.05 ± 22% perf-profile.calltrace.cycles-pp.crypto_alg_lookup.crypto_alg_mod_lookup.crypto_alloc_tfm_node.alg_bind.__sys_bind
0.65 ± 10% +0.4 1.07 ± 22% perf-profile.calltrace.cycles-pp.crypto_alg_mod_lookup.crypto_alloc_tfm_node.alg_bind.__sys_bind.__x64_sys_bind
0.09 ±223% +0.5 0.58 perf-profile.calltrace.cycles-pp.copy_msghdr_from_user.___sys_sendmsg.__sys_sendmsg.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.86 ± 10% +0.5 1.37 perf-profile.calltrace.cycles-pp.restore_fpregs_from_fpstate.switch_fpu_return.arch_exit_to_user_mode_prepare.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.00 +0.5 0.51 perf-profile.calltrace.cycles-pp.__crypto_xor.crypto_cbc_decrypt_segment.crypto_cbc_decrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg
0.82 ± 9% +0.5 1.35 ± 19% perf-profile.calltrace.cycles-pp.crypto_alloc_tfm_node.alg_bind.__sys_bind.__x64_sys_bind.do_syscall_64
0.95 ± 10% +0.6 1.52 perf-profile.calltrace.cycles-pp.switch_fpu_return.arch_exit_to_user_mode_prepare.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg
0.96 ± 10% +0.6 1.52 perf-profile.calltrace.cycles-pp.arch_exit_to_user_mode_prepare.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
2.14 ± 10% +0.6 2.78 perf-profile.calltrace.cycles-pp.af_alg_sendmsg.____sys_sendmsg.___sys_sendmsg.__sys_sendmsg.do_syscall_64
1.10 ± 10% +0.6 1.74 ± 16% perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind.stress_af_alg.stress_run
1.10 ± 10% +0.6 1.74 ± 16% perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.bind.stress_af_alg.stress_run
1.10 ± 10% +0.6 1.74 ± 16% perf-profile.calltrace.cycles-pp.__x64_sys_bind.do_syscall_64.entry_SYSCALL_64_after_hwframe.bind.stress_af_alg
1.12 ± 10% +0.6 1.76 ± 16% perf-profile.calltrace.cycles-pp.bind.stress_af_alg.stress_run
2.82 ± 10% +0.8 3.62 perf-profile.calltrace.cycles-pp.____sys_sendmsg.___sys_sendmsg.__sys_sendmsg.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.00 +0.9 0.92 ± 11% perf-profile.calltrace.cycles-pp.__pi_memcpy.crypto_cbc_encrypt_segment.crypto_cbc_encrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg
3.36 ± 10% +0.9 4.30 perf-profile.calltrace.cycles-pp.__sys_sendmsg.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
3.30 ± 10% +0.9 4.24 perf-profile.calltrace.cycles-pp.___sys_sendmsg.__sys_sendmsg.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg
1.03 ± 21% +1.2 2.20 ± 4% perf-profile.calltrace.cycles-pp.hash_sendmsg.__sys_sendto.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.09 ± 19% +1.3 2.38 ± 4% perf-profile.calltrace.cycles-pp.__sys_sendto.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg
1.09 ± 19% +1.3 2.38 ± 4% perf-profile.calltrace.cycles-pp.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
4.51 ± 10% +1.5 5.98 perf-profile.calltrace.cycles-pp.stress_rndbuf.stress_af_alg.stress_run
0.64 ± 8% +5.1 5.73 perf-profile.calltrace.cycles-pp.des_decrypt.crypto_ecb_decrypt2.crypto_cbc_decrypt_segment.crypto_cbc_decrypt.crypto_lskcipher_crypt_sg
0.57 ± 45% +5.4 6.00 perf-profile.calltrace.cycles-pp.des_encrypt.crypto_ecb_encrypt2.crypto_cbc_encrypt_segment.crypto_cbc_encrypt.crypto_lskcipher_crypt_sg
5.92 ± 7% +6.1 12.03 perf-profile.calltrace.cycles-pp.crypto_ecb_encrypt2.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg
5.89 ± 7% +6.2 12.06 perf-profile.calltrace.cycles-pp.crypto_ecb_decrypt2.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg
1.30 ± 8% +10.3 11.64 perf-profile.calltrace.cycles-pp.des_decrypt.crypto_ecb_decrypt2.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg
1.25 ± 15% +10.4 11.62 perf-profile.calltrace.cycles-pp.des_encrypt.crypto_ecb_encrypt2.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg
1.46 ± 9% +11.9 13.38 ± 17% perf-profile.calltrace.cycles-pp.des3_ede_decrypt.crypto_ecb_decrypt2.crypto_cbc_decrypt_segment.crypto_cbc_decrypt.crypto_lskcipher_crypt_sg
1.77 ± 7% +14.1 15.92 ± 2% perf-profile.calltrace.cycles-pp.des3_ede_encrypt.crypto_ecb_encrypt2.crypto_cbc_encrypt_segment.crypto_cbc_encrypt.crypto_lskcipher_crypt_sg
19.35 ± 12% +19.8 39.20 perf-profile.calltrace.cycles-pp.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg
19.37 ± 12% +19.8 39.22 perf-profile.calltrace.cycles-pp.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
2.99 ± 7% +20.2 23.20 perf-profile.calltrace.cycles-pp.crypto_ecb_decrypt2.crypto_cbc_decrypt_segment.crypto_cbc_decrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg
18.47 ± 12% +20.4 38.89 perf-profile.calltrace.cycles-pp._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg.sock_read_iter.vfs_read
18.59 ± 12% +20.5 39.04 perf-profile.calltrace.cycles-pp.skcipher_recvmsg.sock_recvmsg.sock_read_iter.vfs_read.ksys_read
3.09 ± 7% +20.8 23.88 perf-profile.calltrace.cycles-pp.crypto_cbc_decrypt_segment.crypto_cbc_decrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg
3.10 ± 7% +20.8 23.91 perf-profile.calltrace.cycles-pp.crypto_cbc_decrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg
20.48 ± 15% +21.0 41.45 perf-profile.calltrace.cycles-pp.sock_recvmsg.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe
20.63 ± 15% +21.1 41.69 perf-profile.calltrace.cycles-pp.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg
20.63 ± 15% +21.1 41.70 perf-profile.calltrace.cycles-pp.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
3.10 ± 7% +21.1 24.21 perf-profile.calltrace.cycles-pp.crypto_ecb_encrypt2.crypto_cbc_encrypt_segment.crypto_cbc_encrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg
19.63 ± 15% +21.4 41.00 perf-profile.calltrace.cycles-pp._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg.__sys_recvfrom.__x64_sys_recvfrom
19.74 ± 15% +21.4 41.15 perf-profile.calltrace.cycles-pp.skcipher_recvmsg.sock_recvmsg.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64
3.31 ± 7% +22.3 25.62 perf-profile.calltrace.cycles-pp.crypto_cbc_encrypt_segment.crypto_cbc_encrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg
3.31 ± 7% +22.3 25.65 perf-profile.calltrace.cycles-pp.crypto_cbc_encrypt.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg
9.04 ± 7% +27.1 36.17 perf-profile.calltrace.cycles-pp.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg.sock_read_iter
9.29 ± 7% +28.6 37.88 perf-profile.calltrace.cycles-pp.crypto_lskcipher_crypt_sg._skcipher_recvmsg.skcipher_recvmsg.sock_recvmsg.__sys_recvfrom
45.82 ± 11% +44.0 89.81 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
45.90 ± 11% +44.0 89.92 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.stress_af_alg.stress_run
52.97 ± 9% +47.2 100.15 perf-profile.calltrace.cycles-pp.stress_af_alg.stress_run
46.48 ± 10% -46.5 0.00 perf-profile.children.cycles-pp.jent_gen_entropy
46.45 ± 10% -46.5 0.00 perf-profile.children.cycles-pp.jent_measure_jitter
43.78 ± 10% -43.8 0.00 perf-profile.children.cycles-pp._rng_recvmsg
43.77 ± 10% -43.8 0.00 perf-profile.children.cycles-pp.jent_kcapi_random
43.77 ± 10% -43.8 0.00 perf-profile.children.cycles-pp.jent_read_entropy
36.69 ± 10% -36.7 0.00 perf-profile.children.cycles-pp.jent_condition_data
36.66 ± 10% -36.7 0.00 perf-profile.children.cycles-pp.jent_hash_time
33.20 ± 10% -33.2 0.00 perf-profile.children.cycles-pp.sha3_final
31.96 ± 10% -32.0 0.00 perf-profile.children.cycles-pp.sha3_keccakf_one_round_generic
63.08 ± 3% -23.9 39.14 perf-profile.children.cycles-pp.sock_read_iter
63.14 ± 3% -23.9 39.20 perf-profile.children.cycles-pp.vfs_read
63.16 ± 3% -23.9 39.23 perf-profile.children.cycles-pp.ksys_read
9.75 ± 22% -9.8 0.00 perf-profile.children.cycles-pp.crypto_ctr_crypt
9.61 ± 9% -9.6 0.00 perf-profile.children.cycles-pp.jent_memaccess
83.50 -3.0 80.51 perf-profile.children.cycles-pp.sock_recvmsg
2.90 ± 10% -2.6 0.28 ± 7% perf-profile.children.cycles-pp.crypto_create_tfm_node
3.56 ± 10% -2.2 1.35 ± 19% perf-profile.children.cycles-pp.crypto_alloc_tfm_node
3.82 ± 10% -2.1 1.71 ± 16% perf-profile.children.cycles-pp.alg_bind
3.84 ± 10% -2.1 1.74 ± 16% perf-profile.children.cycles-pp.__sys_bind
3.84 ± 10% -2.1 1.74 ± 16% perf-profile.children.cycles-pp.__x64_sys_bind
3.86 ± 10% -2.1 1.77 ± 16% perf-profile.children.cycles-pp.bind
93.79 -2.1 91.71 perf-profile.children.cycles-pp.do_syscall_64
93.86 -2.0 91.82 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
0.32 ± 14% -0.3 0.04 ± 73% perf-profile.children.cycles-pp.process_simple
0.31 ± 14% -0.3 0.04 ± 73% perf-profile.children.cycles-pp.ordered_events__queue
0.31 ± 14% -0.3 0.04 ± 73% perf-profile.children.cycles-pp.queue_event
0.25 ± 40% -0.2 0.07 ± 5% perf-profile.children.cycles-pp.alg_setsockopt
0.22 ± 44% -0.2 0.05 perf-profile.children.cycles-pp.crypto_skcipher_setkey
0.25 ± 39% -0.2 0.08 ± 4% perf-profile.children.cycles-pp.do_sock_setsockopt
0.25 ± 39% -0.2 0.08 perf-profile.children.cycles-pp.__sys_setsockopt
0.25 ± 39% -0.2 0.08 perf-profile.children.cycles-pp.__x64_sys_setsockopt
0.28 ± 34% -0.2 0.12 perf-profile.children.cycles-pp.setsockopt
0.09 ± 17% -0.0 0.04 ± 45% perf-profile.children.cycles-pp.handle_internal_command
0.09 ± 17% -0.0 0.04 ± 45% perf-profile.children.cycles-pp.main
0.07 ± 11% -0.0 0.04 ± 71% perf-profile.children.cycles-pp.ktime_get_update_offsets_now
0.14 ± 11% -0.0 0.12 ± 14% perf-profile.children.cycles-pp.strcmp
0.06 ± 7% +0.0 0.08 perf-profile.children.cycles-pp.__virt_addr_valid
0.06 ± 9% +0.0 0.07 perf-profile.children.cycles-pp.af_alg_wmem_wakeup
0.06 ± 9% +0.0 0.08 perf-profile.children.cycles-pp.handle_softirqs
0.12 ± 10% +0.0 0.15 ± 3% perf-profile.children.cycles-pp.rmqueue
0.10 ± 13% +0.0 0.13 ± 2% perf-profile.children.cycles-pp.fdget
0.12 ± 11% +0.0 0.15 ± 2% perf-profile.children.cycles-pp._raw_spin_trylock
0.06 ± 14% +0.0 0.09 ± 5% perf-profile.children.cycles-pp.__irq_exit_rcu
0.13 ± 8% +0.0 0.16 perf-profile.children.cycles-pp.check_heap_object
0.04 ± 45% +0.0 0.08 perf-profile.children.cycles-pp.x64_sys_call
0.12 ± 8% +0.0 0.16 ± 6% perf-profile.children.cycles-pp.crypto_spawn_alg
0.14 ± 11% +0.0 0.18 ± 2% perf-profile.children.cycles-pp.__free_frozen_pages
0.07 ± 11% +0.0 0.10 ± 7% perf-profile.children.cycles-pp.crypto_spawn_tfm
0.08 ± 16% +0.0 0.12 ± 6% perf-profile.children.cycles-pp.get_jiffies_update
0.12 ± 11% +0.0 0.16 ± 10% perf-profile.children.cycles-pp.crypto_mod_put
0.08 ± 20% +0.0 0.13 ± 5% perf-profile.children.cycles-pp.tmigr_requires_handle_remote
0.21 ± 8% +0.0 0.25 ± 5% perf-profile.children.cycles-pp.get_page_from_freelist
0.03 ±100% +0.0 0.07 perf-profile.children.cycles-pp.__check_heap_object
0.02 ± 99% +0.0 0.07 perf-profile.children.cycles-pp.rcu_core
0.06 ± 7% +0.0 0.11 perf-profile.children.cycles-pp.stress_time_now_timespec
0.08 ± 13% +0.0 0.13 perf-profile.children.cycles-pp.entry_SYSCALL_64_safe_stack
0.09 ± 10% +0.1 0.14 ± 2% perf-profile.children.cycles-pp.__fput
0.00 +0.1 0.05 perf-profile.children.cycles-pp.prandom_u32_state
0.00 +0.1 0.05 ± 8% perf-profile.children.cycles-pp.kmem_cache_alloc_lru_noprof
0.02 ±141% +0.1 0.07 perf-profile.children.cycles-pp.dentry_kill
0.02 ±141% +0.1 0.07 perf-profile.children.cycles-pp.finish_dput
0.03 ±100% +0.1 0.08 ± 4% perf-profile.children.cycles-pp.af_alg_accept
0.27 ± 8% +0.1 0.32 ± 4% perf-profile.children.cycles-pp.__alloc_frozen_pages_noprof
0.02 ± 99% +0.1 0.08 ± 4% perf-profile.children.cycles-pp.sock_alloc
0.24 ± 9% +0.1 0.30 perf-profile.children.cycles-pp.kfree
0.00 +0.1 0.06 ± 6% perf-profile.children.cycles-pp.__sha256_final
0.20 ± 11% +0.1 0.26 perf-profile.children.cycles-pp.copy_iovec_from_user
0.00 +0.1 0.06 perf-profile.children.cycles-pp.__md5_final
0.10 ± 9% +0.1 0.16 ± 2% perf-profile.children.cycles-pp.__x64_sys_close
0.00 +0.1 0.06 perf-profile.children.cycles-pp.alloc_file_pseudo
0.00 +0.1 0.06 perf-profile.children.cycles-pp.hash_alloc_result
0.00 +0.1 0.06 perf-profile.children.cycles-pp.import_ubuf
0.00 +0.1 0.06 perf-profile.children.cycles-pp.kmem_cache_free
0.00 +0.1 0.06 perf-profile.children.cycles-pp.rcu_do_batch
0.02 ±141% +0.1 0.08 perf-profile.children.cycles-pp.alloc_inode
0.00 +0.1 0.06 ± 7% perf-profile.children.cycles-pp.sock_alloc_file
0.32 ± 8% +0.1 0.38 ± 3% perf-profile.children.cycles-pp.alloc_pages_mpol
0.00 +0.1 0.06 ± 11% perf-profile.children.cycles-pp.map_symbol__exit
0.43 ± 9% +0.1 0.49 ± 2% perf-profile.children.cycles-pp.sysvec_apic_timer_interrupt
0.22 ± 8% +0.1 0.29 perf-profile.children.cycles-pp.__check_object_size
0.00 +0.1 0.07 ± 5% perf-profile.children.cycles-pp.crypto_lskcipher_decrypt
0.34 ± 9% +0.1 0.41 ± 2% perf-profile.children.cycles-pp.alloc_pages_noprof
0.24 ± 10% +0.1 0.31 perf-profile.children.cycles-pp.__import_iovec
0.27 ± 10% +0.1 0.34 ± 2% perf-profile.children.cycles-pp.af_alg_pull_tsgl
0.07 ± 11% +0.1 0.14 ± 12% perf-profile.children.cycles-pp.alg_get_type
0.00 +0.1 0.07 ± 18% perf-profile.children.cycles-pp.crypto_ahash_init_tfm
0.24 ± 10% +0.1 0.32 perf-profile.children.cycles-pp.import_iovec
0.13 ± 11% +0.1 0.21 perf-profile.children.cycles-pp.lock_sock_nested
0.13 ± 9% +0.1 0.21 perf-profile.children.cycles-pp._raw_spin_lock_bh
0.00 +0.1 0.08 perf-profile.children.cycles-pp._copy_to_iter
0.00 +0.1 0.08 ± 8% perf-profile.children.cycles-pp.crypto_lskcipher_encrypt
0.02 ± 99% +0.1 0.11 perf-profile.children.cycles-pp.sock_kzfree_s
0.00 +0.1 0.09 ± 15% perf-profile.children.cycles-pp.lskcipher_init_tfm_simple
0.34 ± 10% +0.1 0.42 perf-profile.children.cycles-pp.af_alg_alloc_areq
0.15 ± 11% +0.1 0.24 perf-profile.children.cycles-pp.release_sock
0.14 ± 10% +0.1 0.24 ± 7% perf-profile.children.cycles-pp.__local_bh_enable_ip
0.13 ± 10% +0.1 0.23 perf-profile.children.cycles-pp.do_accept
0.14 ± 8% +0.1 0.24 perf-profile.children.cycles-pp.__sys_accept4
0.14 ± 8% +0.1 0.24 ± 2% perf-profile.children.cycles-pp.__x64_sys_accept
0.01 ±223% +0.1 0.12 ± 4% perf-profile.children.cycles-pp.hash_check_key
0.00 +0.1 0.11 ± 4% perf-profile.children.cycles-pp.lskcipher_init_tfm_simple2
0.42 ± 9% +0.1 0.53 perf-profile.children.cycles-pp.sock_kfree_s
0.00 +0.1 0.11 ± 7% perf-profile.children.cycles-pp.aes_xts_decrypt_vaes_avx2
0.00 +0.1 0.11 ± 5% perf-profile.children.cycles-pp.aes_xts_encrypt_vaes_avx2
0.00 +0.1 0.11 perf-profile.children.cycles-pp.aesni_cbc_dec
0.01 ±223% +0.1 0.12 ± 3% perf-profile.children.cycles-pp.hash_sendmsg_nokey
0.39 ± 10% +0.1 0.50 perf-profile.children.cycles-pp._copy_from_iter
0.42 ± 11% +0.1 0.54 perf-profile.children.cycles-pp.sock_kmalloc
0.00 +0.1 0.12 perf-profile.children.cycles-pp.sha1_ni_transform
0.03 ±100% +0.1 0.15 ± 5% perf-profile.children.cycles-pp.crypto_init_lskcipher_ops_sg
0.40 ± 9% +0.1 0.52 perf-profile.children.cycles-pp._copy_from_user
0.45 ± 10% +0.1 0.58 perf-profile.children.cycles-pp.copy_msghdr_from_user
0.03 ±102% +0.2 0.19 ± 10% perf-profile.children.cycles-pp.thread__resolve_callchain_sample
0.02 ±142% +0.2 0.18 ± 10% perf-profile.children.cycles-pp.add_callchain_ip
0.00 +0.2 0.17 ± 28% perf-profile.children.cycles-pp.xts_decrypt_vaes_avx2
0.02 ±141% +0.2 0.19 ± 5% perf-profile.children.cycles-pp.aes_ctr64_crypt_vaes_avx2
0.00 +0.2 0.17 ± 29% perf-profile.children.cycles-pp.xts_encrypt_vaes_avx2
0.31 ± 11% +0.2 0.49 perf-profile.children.cycles-pp.entry_SYSCALL_64
0.09 ± 8% +0.2 0.27 perf-profile.children.cycles-pp.hash_recvmsg
0.04 ±104% +0.2 0.23 ± 9% perf-profile.children.cycles-pp.__thread__resolve_callchain
0.04 ±104% +0.2 0.23 ± 9% perf-profile.children.cycles-pp.sample__for_each_callchain_node
0.00 +0.2 0.20 ± 2% perf-profile.children.cycles-pp._aesni_enc4
0.00 +0.2 0.20 perf-profile.children.cycles-pp.sha1_update
0.04 ±102% +0.2 0.24 ± 8% perf-profile.children.cycles-pp.build_id__mark_dso_hit
0.64 ± 12% +0.2 0.84 ± 5% perf-profile.children.cycles-pp.af_alg_free_resources
0.00 +0.2 0.21 perf-profile.children.cycles-pp.aesni_ecb_dec
0.00 +0.2 0.21 perf-profile.children.cycles-pp.sha1_blocks_ni
0.11 ± 8% +0.2 0.32 ± 12% perf-profile.children.cycles-pp.skcipher_walk_virt
0.00 +0.2 0.22 perf-profile.children.cycles-pp.aesni_ecb_enc
0.04 ±102% +0.2 0.27 ± 11% perf-profile.children.cycles-pp.ordered_events__deliver_event
0.04 ±102% +0.2 0.27 ± 11% perf-profile.children.cycles-pp.perf_session__deliver_event
0.04 ±102% +0.2 0.28 ± 11% perf-profile.children.cycles-pp.__ordered_events__flush
0.05 ± 8% +0.2 0.29 perf-profile.children.cycles-pp._aesni_dec4
0.00 +0.3 0.26 perf-profile.children.cycles-pp.md4_update
0.49 ± 10% +0.3 0.76 perf-profile.children.cycles-pp.entry_SYSRETQ_unsafe_stack
0.00 +0.3 0.27 perf-profile.children.cycles-pp.md4_transform
0.09 ± 8% +0.3 0.36 ± 24% perf-profile.children.cycles-pp.up_read
0.00 +0.3 0.29 perf-profile.children.cycles-pp.sha256_ni_transform
0.12 ± 9% +0.3 0.41 ± 23% perf-profile.children.cycles-pp.down_read
1.00 ± 10% +0.3 1.30 perf-profile.children.cycles-pp.sg_init_table
0.10 ± 11% +0.3 0.45 perf-profile.children.cycles-pp._aesni_enc1
1.25 ± 10% +0.4 1.61 perf-profile.children.cycles-pp.__pi_memset
0.11 ± 6% +0.4 0.48 perf-profile.children.cycles-pp.aesni_cbc_enc
0.09 ± 10% +0.4 0.46 ± 3% perf-profile.children.cycles-pp.ctr_crypt_vaes_avx2
0.65 ± 10% +0.4 1.04 perf-profile.children.cycles-pp.os_xsave
0.66 ± 10% +0.4 1.05 perf-profile.children.cycles-pp.save_fpregs_to_fpstate
0.66 ± 10% +0.4 1.05 ± 22% perf-profile.children.cycles-pp.crypto_alg_lookup
0.03 ±100% +0.4 0.43 ± 2% perf-profile.children.cycles-pp.md5_update
0.66 ± 9% +0.4 1.07 ± 22% perf-profile.children.cycles-pp.crypto_alg_mod_lookup
0.03 ±100% +0.4 0.44 perf-profile.children.cycles-pp.__sha256_update
0.06 ± 9% +0.4 0.47 perf-profile.children.cycles-pp.sha256_blocks_ni
0.06 ± 9% +0.4 0.48 perf-profile.children.cycles-pp.md5_block
0.71 ± 9% +0.4 1.14 perf-profile.children.cycles-pp.kernel_fpu_begin_mask
1.08 ± 10% +0.5 1.56 ± 7% perf-profile.children.cycles-pp.__pi_memcpy
0.87 ± 10% +0.5 1.40 perf-profile.children.cycles-pp.restore_fpregs_from_fpstate
0.96 ± 10% +0.6 1.54 perf-profile.children.cycles-pp.switch_fpu_return
0.97 ± 10% +0.6 1.56 perf-profile.children.cycles-pp.arch_exit_to_user_mode_prepare
2.14 ± 10% +0.6 2.78 perf-profile.children.cycles-pp.af_alg_sendmsg
2.82 ± 10% +0.8 3.62 perf-profile.children.cycles-pp.____sys_sendmsg
3.30 ± 10% +0.9 4.24 perf-profile.children.cycles-pp.___sys_sendmsg
3.36 ± 10% +0.9 4.30 perf-profile.children.cycles-pp.__sys_sendmsg
1.03 ± 21% +1.2 2.20 ± 4% perf-profile.children.cycles-pp.hash_sendmsg
1.09 ± 19% +1.3 2.38 ± 4% perf-profile.children.cycles-pp.__sys_sendto
1.09 ± 19% +1.3 2.38 ± 4% perf-profile.children.cycles-pp.__x64_sys_sendto
4.53 ± 10% +1.5 6.00 perf-profile.children.cycles-pp.stress_rndbuf
9.01 ± 10% +7.3 16.35 perf-profile.children.cycles-pp.des3_ede_encrypt
5.33 ± 10% +10.4 15.77 perf-profile.children.cycles-pp.des3_ede_decrypt
3.13 ± 16% +14.8 17.93 perf-profile.children.cycles-pp.des_encrypt
1.98 ± 10% +15.7 17.68 perf-profile.children.cycles-pp.des_decrypt
3.64 ± 9% +20.3 23.91 perf-profile.children.cycles-pp.crypto_cbc_decrypt
3.63 ± 9% +20.3 23.90 perf-profile.children.cycles-pp.crypto_cbc_decrypt_segment
20.63 ± 15% +21.1 41.69 perf-profile.children.cycles-pp.__sys_recvfrom
20.63 ± 15% +21.1 41.70 perf-profile.children.cycles-pp.__x64_sys_recvfrom
3.89 ± 9% +21.8 25.65 perf-profile.children.cycles-pp.crypto_cbc_encrypt
3.88 ± 9% +21.8 25.64 perf-profile.children.cycles-pp.crypto_cbc_encrypt_segment
9.89 ± 9% +25.4 35.28 perf-profile.children.cycles-pp.crypto_ecb_decrypt2
10.05 ± 8% +26.2 36.25 perf-profile.children.cycles-pp.crypto_ecb_encrypt2
38.11 ± 14% +41.8 79.89 perf-profile.children.cycles-pp._skcipher_recvmsg
38.32 ± 14% +41.9 80.19 perf-profile.children.cycles-pp.skcipher_recvmsg
52.97 ± 9% +46.6 99.59 perf-profile.children.cycles-pp.stress_af_alg
20.45 ± 8% +53.6 74.06 perf-profile.children.cycles-pp.crypto_lskcipher_crypt_sg
31.66 ± 10% -31.7 0.00 perf-profile.self.cycles-pp.sha3_keccakf_one_round_generic
8.76 ± 9% -8.8 0.00 perf-profile.self.cycles-pp.jent_memaccess
0.31 ± 14% -0.3 0.04 ± 73% perf-profile.self.cycles-pp.queue_event
0.14 ± 8% -0.0 0.11 ± 14% perf-profile.self.cycles-pp.strcmp
0.07 ± 11% -0.0 0.04 ± 71% perf-profile.self.cycles-pp.ktime_get_update_offsets_now
0.06 ± 11% +0.0 0.08 ± 6% perf-profile.self.cycles-pp.__virt_addr_valid
0.06 ± 9% +0.0 0.07 perf-profile.self.cycles-pp.af_alg_wmem_wakeup
0.06 ± 11% +0.0 0.08 ± 6% perf-profile.self.cycles-pp.check_heap_object
0.07 ± 11% +0.0 0.09 ± 5% perf-profile.self.cycles-pp.sock_read_iter
0.06 ± 13% +0.0 0.08 perf-profile.self.cycles-pp.____sys_sendmsg
0.06 ± 9% +0.0 0.08 ± 8% perf-profile.self.cycles-pp.kernel_fpu_begin_mask
0.10 ± 11% +0.0 0.13 ± 2% perf-profile.self.cycles-pp.fdget
0.08 ± 9% +0.0 0.11 ± 7% perf-profile.self.cycles-pp.sg_init_table
0.10 ± 13% +0.0 0.14 ± 5% perf-profile.self.cycles-pp.af_alg_get_rsgl
0.07 ± 11% +0.0 0.10 perf-profile.self.cycles-pp.entry_SYSCALL_64_safe_stack
0.02 ± 99% +0.0 0.06 perf-profile.self.cycles-pp._skcipher_recvmsg
0.06 ± 11% +0.0 0.10 perf-profile.self.cycles-pp.entry_SYSCALL_64_after_hwframe
0.11 ± 10% +0.0 0.15 perf-profile.self.cycles-pp._raw_spin_trylock
0.08 ± 16% +0.0 0.12 ± 6% perf-profile.self.cycles-pp.get_jiffies_update
0.11 ± 14% +0.0 0.15 ± 11% perf-profile.self.cycles-pp.gup_fast_pgd_range
0.04 ± 71% +0.0 0.08 ± 6% perf-profile.self.cycles-pp.x64_sys_call
0.20 ± 12% +0.0 0.24 perf-profile.self.cycles-pp.__kmalloc_noprof
0.03 ±100% +0.0 0.07 perf-profile.self.cycles-pp.__check_heap_object
0.06 ± 9% +0.0 0.10 ± 3% perf-profile.self.cycles-pp.stress_time_now_timespec
0.12 ± 9% +0.0 0.16 ± 10% perf-profile.self.cycles-pp.crypto_mod_put
0.03 ±100% +0.0 0.07 ± 6% perf-profile.self.cycles-pp.extract_iter_to_sg
0.00 +0.1 0.05 perf-profile.self.cycles-pp.__check_object_size
0.00 +0.1 0.05 perf-profile.self.cycles-pp.__free_frozen_pages
0.00 +0.1 0.05 perf-profile.self.cycles-pp.import_ubuf
0.00 +0.1 0.05 perf-profile.self.cycles-pp.prandom_u32_state
0.00 +0.1 0.05 perf-profile.self.cycles-pp.rmqueue
0.10 ± 9% +0.1 0.15 perf-profile.self.cycles-pp.do_syscall_64
0.02 ± 99% +0.1 0.08 ± 4% perf-profile.self.cycles-pp.gup_fast
0.00 +0.1 0.05 ± 8% perf-profile.self.cycles-pp.crypto_lskcipher_decrypt
0.01 ±223% +0.1 0.06 ± 6% perf-profile.self.cycles-pp.iov_iter_extract_pages
0.17 ± 10% +0.1 0.23 ± 2% perf-profile.self.cycles-pp.af_alg_pull_tsgl
0.09 ± 11% +0.1 0.14 ± 3% perf-profile.self.cycles-pp.switch_fpu_return
0.10 ± 11% +0.1 0.16 perf-profile.self.cycles-pp.__sys_recvfrom
0.20 ± 11% +0.1 0.26 perf-profile.self.cycles-pp.copy_iovec_from_user
0.20 ± 10% +0.1 0.26 perf-profile.self.cycles-pp.af_alg_sendmsg
0.23 ± 9% +0.1 0.30 perf-profile.self.cycles-pp.kfree
0.22 ± 10% +0.1 0.29 perf-profile.self.cycles-pp.sock_kfree_s
0.00 +0.1 0.08 ± 6% perf-profile.self.cycles-pp._copy_to_iter
0.14 ± 11% +0.1 0.21 ± 4% perf-profile.self.cycles-pp.af_alg_free_resources
0.22 ± 11% +0.1 0.30 perf-profile.self.cycles-pp.sock_kmalloc
0.13 ± 9% +0.1 0.21 perf-profile.self.cycles-pp.lock_sock_nested
0.13 ± 10% +0.1 0.21 perf-profile.self.cycles-pp._raw_spin_lock_bh
0.00 +0.1 0.08 ± 4% perf-profile.self.cycles-pp.crypto_lskcipher_encrypt
0.13 ± 11% +0.1 0.23 ± 7% perf-profile.self.cycles-pp.__local_bh_enable_ip
0.00 +0.1 0.11 ± 4% perf-profile.self.cycles-pp.aes_xts_encrypt_vaes_avx2
0.00 +0.1 0.11 ± 8% perf-profile.self.cycles-pp.aes_xts_decrypt_vaes_avx2
0.00 +0.1 0.11 ± 10% perf-profile.self.cycles-pp.crypto_cbc_encrypt_segment
0.38 ± 9% +0.1 0.49 perf-profile.self.cycles-pp._copy_from_iter
0.00 +0.1 0.11 ± 4% perf-profile.self.cycles-pp.crypto_cbc_decrypt_segment
0.00 +0.1 0.12 perf-profile.self.cycles-pp.sha1_ni_transform
0.40 ± 10% +0.1 0.52 perf-profile.self.cycles-pp._copy_from_user
0.02 ±141% +0.2 0.19 ± 5% perf-profile.self.cycles-pp.aes_ctr64_crypt_vaes_avx2
0.31 ± 10% +0.2 0.48 perf-profile.self.cycles-pp.entry_SYSCALL_64
0.00 +0.2 0.20 ± 2% perf-profile.self.cycles-pp._aesni_enc4
0.11 ± 10% +0.2 0.32 ± 12% perf-profile.self.cycles-pp.skcipher_walk_virt
0.05 ± 8% +0.2 0.28 perf-profile.self.cycles-pp._aesni_dec4
0.49 ± 10% +0.3 0.75 perf-profile.self.cycles-pp.entry_SYSRETQ_unsafe_stack
0.00 +0.3 0.27 perf-profile.self.cycles-pp.md4_transform
0.09 ± 8% +0.3 0.36 ± 24% perf-profile.self.cycles-pp.up_read
0.00 +0.3 0.29 perf-profile.self.cycles-pp.sha256_ni_transform
0.12 ± 9% +0.3 0.41 ± 24% perf-profile.self.cycles-pp.down_read
0.10 ± 11% +0.3 0.45 perf-profile.self.cycles-pp._aesni_enc1
1.24 ± 10% +0.4 1.60 perf-profile.self.cycles-pp.__pi_memset
0.65 ± 10% +0.4 1.04 perf-profile.self.cycles-pp.os_xsave
0.06 ± 9% +0.4 0.48 perf-profile.self.cycles-pp.md5_block
1.07 ± 10% +0.5 1.53 ± 7% perf-profile.self.cycles-pp.__pi_memcpy
0.87 ± 10% +0.5 1.40 perf-profile.self.cycles-pp.restore_fpregs_from_fpstate
4.50 ± 10% +1.5 5.96 perf-profile.self.cycles-pp.stress_rndbuf
0.17 ± 13% +1.6 1.79 ± 5% perf-profile.self.cycles-pp.crypto_ecb_decrypt2
0.17 ± 13% +1.8 1.92 ± 6% perf-profile.self.cycles-pp.crypto_ecb_encrypt2
8.96 ± 10% +7.3 16.25 perf-profile.self.cycles-pp.des3_ede_encrypt
5.30 ± 10% +10.4 15.69 perf-profile.self.cycles-pp.des3_ede_decrypt
3.10 ± 17% +14.7 17.81 perf-profile.self.cycles-pp.des_encrypt
1.96 ± 10% +15.6 17.55 perf-profile.self.cycles-pp.des_decrypt
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [RFC PATCH net-next v2 2/2] selftests/net: packetdrill: Add two tcp_purge_receive_queue tests
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260715145328.54597-1-leon.hwang@linux.dev>
Run the tests:
# ./ksft_runner.sh ./tcp_purge_receive_queue_disabled.pkt
TAP version 13
1..3
ok 1 ipv4
ok 2 ipv6
ok 3 ipv4-mapped-ipv6
# Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
# ./ksft_runner.sh ./tcp_purge_receive_queue_enabled.pkt
TAP version 13
1..3
ok 1 ipv4
ok 2 ipv6
ok 3 ipv4-mapped-ipv6
# Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
Assisted-by: Codex:gpt-5.5
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
.../tcp_purge_receive_queue_disabled.pkt | 40 ++++++++++++++++++
.../tcp_purge_receive_queue_enabled.pkt | 42 +++++++++++++++++++
2 files changed, 82 insertions(+)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
diff --git a/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
new file mode 100644
index 000000000000..a46f93eaab1f
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+// Test: with tcp_purge_receive_queue disabled (default), receiving RST
+// in CLOSE_WAIT state does NOT purge the receive queue.
+// The unread data in the receive queue is still accessible to the
+// application.
+
+`./defaults.sh
+./set_sysctls.py /proc/sys/net/ipv4/tcp_purge_receive_queue=0`
+
+// Establish a connection (server side).
+ 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+ +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+ +0 bind(3, ..., ...) = 0
+ +0 listen(3, 1) = 0
+
+ +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+ +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
+ +.1 < . 1:1(0) ack 1 win 257
+
+ +0 accept(3, ..., ...) = 4
+
+// Remote sends 4KiB data so that receive queue is populated.
+ +.1 < . 1:4097(4096) ack 1 win 257
+ +0 > . 1:1(0) ack 4097
+
+// Remote sends FIN -> socket enters CLOSE_WAIT.
+ +.1 < F. 4097:4097(0) ack 1 win 257
+ +0~+.04 > . 1:1(0) ack 4098
+
+// Inject RST directly while in CLOSE_WAIT.
+ +.1 < R. 4098:4098(0) ack 1 win 257
+
+// With tcp_purge_receive_queue=0, the receive queue is NOT purged.
+// Data is still in the receive queue; read returns data.
+ +0 read(4, ..., 1) = 1
+
+ +0 close(4) = 0
+
+// Restore sysctls.
+`/tmp/sysctl_restore_${PPID}.sh`
diff --git a/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
new file mode 100644
index 000000000000..b1d1dff28f50
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+// Test: with tcp_purge_receive_queue enabled, receiving RST in
+// CLOSE_WAIT state purges the receive queue immediately.
+// The unread data is discarded, so read() observes EOF.
+//
+// RFC 9293 Section 3.10.7.4:
+// "all segment queues should be flushed"
+
+`./defaults.sh
+./set_sysctls.py /proc/sys/net/ipv4/tcp_purge_receive_queue=1`
+
+// Establish a connection (server side).
+ 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+ +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+ +0 bind(3, ..., ...) = 0
+ +0 listen(3, 1) = 0
+
+ +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+ +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
+ +.1 < . 1:1(0) ack 1 win 257
+
+ +0 accept(3, ..., ...) = 4
+
+// Remote sends 4KiB data so that receive queue is populated.
+ +.1 < . 1:4097(4096) ack 1 win 257
+ +0 > . 1:1(0) ack 4097
+
+// Remote sends FIN -> socket enters CLOSE_WAIT.
+ +.1 < F. 4097:4097(0) ack 1 win 257
+ +0~+.04 > . 1:1(0) ack 4098
+
+// Inject RST directly while in CLOSE_WAIT.
+ +.1 < R. 4098:4098(0) ack 1 win 257
+
+// With tcp_purge_receive_queue=1, the receive queue IS purged.
+// Queue was purged by RST handler; read returns EOF.
+ +0 read(4, ..., 1) = 0
+
+ +0 close(4) = 0
+
+// Restore sysctls.
+`/tmp/sysctl_restore_${PPID}.sh`
--
2.55.0
^ permalink raw reply related
* [RFC PATCH net-next v2 0/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
address an unreleased SKBs issue related to TCP sockets.
Issue:
When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
current implementation does not clear the socket's receive queue. This
causes SKBs in the queue to remain allocated until the socket is
explicitly closed by the application. As a consequence:
1. The page pool pages held by these SKBs are not released.
2. The associated page pool cannot be freed.
RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
CLOSE_WAIT state, "all segment queues should be flushed." However, the
current implementation does not flush the receive queue.
Solution:
Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
when enabled, causes the kernel to purge the receive queue when a RST
packet is received in CLOSE_WAIT state. This allows immediate release
of SKBs and their associated memory resources.
The feature is disabled by default to maintain backward compatibility
with existing behavior.
Note: the user-space issue, the root cause of the unreleased SKBs, has
been fixed by https://github.com/IBM/sarama/pull/3384.
Changes:
v1 -> v2:
* Update 'tp->copied_seq', 'tp->urg_data', and 'sk->sk_peek_off' like
'tcp_disconnect()'.
* Drop "memory leak" words in commit msg. (per Eric)
* Add two packetdrill tests. (per Eric)
* v1: https://lore.kernel.org/netdev/20260225074633.149590-1-leon.huangfu@shopee.com/
Leon Hwang (2):
tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
selftests/net: packetdrill: Add two tcp_purge_receive_queue tests
Documentation/networking/ip-sysctl.rst | 18 ++++++++
.../net_cachelines/netns_ipv4_sysctl.rst | 1 +
include/net/netns/ipv4.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 9 ++++
net/ipv4/tcp_input.c | 22 ++++++++++
.../tcp_purge_receive_queue_disabled.pkt | 40 ++++++++++++++++++
.../tcp_purge_receive_queue_enabled.pkt | 42 +++++++++++++++++++
7 files changed, 133 insertions(+)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
--
2.55.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox