* Re: [PATCH v6 05/15] mm: add VM_UFFD_RWP VMA flag
From: Lorenzo Stoakes @ 2026-06-03 12:52 UTC (permalink / raw)
To: Kiryl Shutsemau (Meta)
Cc: akpm, rppt, peterx, david, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team
In-Reply-To: <20260529172716.357179-6-kas@kernel.org>
On Fri, May 29, 2026 at 06:26:34PM +0100, Kiryl Shutsemau (Meta) wrote:
> Preparatory patch for userfaultfd read-write protection (RWP). RWP
> extends userfaultfd protection from plain write-protection (WP) to
> full read-write protection: accesses to an RWP-protected range --
> reads as well as writes -- trap through userfaultfd.
>
> Reserve VM_UFFD_RWP, add the userfaultfd_rwp() and
> userfaultfd_protected() helpers, and wire up the smaps "ur" entry and
> the trace-flag table the rest of the series will use. The flag is
> gated on CONFIG_USERFAULTFD_RWP, which is introduced together with the
> UAPI in a later patch; until then VM_UFFD_RWP aliases VM_NONE and
> every downstream check folds to dead code.
>
> Nothing sets or queries the flag yet.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-6
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Reviewed-by: SeongJae Park <sj@kernel.org>
LGTM, so:
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> Documentation/filesystems/proc.rst | 1 +
> fs/proc/task_mmu.c | 3 +++
> include/linux/mm.h | 41 ++++++++++++++++++++----------
> include/linux/userfaultfd_k.h | 32 +++++++++++++++++++----
> include/trace/events/mmflags.h | 7 +++++
> 5 files changed, 65 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index db6167befb7b..db28207c5290 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -607,6 +607,7 @@ encoded manner. The codes are the following:
> um userfaultfd missing tracking
> uw userfaultfd wr-protect tracking
> ui userfaultfd minor fault
> + ur userfaultfd read-write-protect tracking
> ss shadow/guarded control stack page
> sl sealed
> lf lock on fault pages
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 939657aa334a..ca0f69b347e8 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1237,6 +1237,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
> [ilog2(VM_UFFD_MINOR)] = "ui",
> #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> +#ifdef CONFIG_USERFAULTFD_RWP
> + [ilog2(VM_UFFD_RWP)] = "ur",
> +#endif
> #ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
> [ilog2(VM_SHADOW_STACK)] = "ss",
> #endif
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 485df9c2dbdd..5ac31fbadeef 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -353,6 +353,7 @@ enum {
> #endif
> DECLARE_VMA_BIT(UFFD_MINOR, 41),
> DECLARE_VMA_BIT(SEALED, 42),
> + DECLARE_VMA_BIT(UFFD_RWP, 43),
> /* Flags that reuse flags above. */
> DECLARE_VMA_BIT_ALIAS(PKEY_BIT0, HIGH_ARCH_0),
> DECLARE_VMA_BIT_ALIAS(PKEY_BIT1, HIGH_ARCH_1),
> @@ -496,12 +497,17 @@ enum {
> #else
> #define VM_UFFD_MINOR VM_NONE
> #endif
> +#ifdef CONFIG_USERFAULTFD_RWP
> +#define VM_UFFD_RWP INIT_VM_FLAG(UFFD_RWP)
> +#else
> +#define VM_UFFD_RWP VM_NONE
> +#endif
>
> /*
> - * vma_flags_t masks for the userfaultfd VMA flags. VMA_UFFD_MINOR is gated on
> - * the same config as VM_UFFD_MINOR -- which implies 64BIT, where the bit fits
> - * -- so an out-of-range bit is never fed to mk_vma_flags() on a build whose
> - * bitmap cannot hold it.
> + * vma_flags_t masks for the userfaultfd VMA flags. The two high-bit modes are
> + * gated on the same configs as their VM_* flags above -- both of which imply
> + * 64BIT -- so an out-of-range bit is never fed to mk_vma_flags() on a build
> + * whose bitmap cannot hold it.
> */
> #define VMA_UFFD_MISSING mk_vma_flags(VMA_UFFD_MISSING_BIT)
> #define VMA_UFFD_WP mk_vma_flags(VMA_UFFD_WP_BIT)
> @@ -510,6 +516,11 @@ enum {
> #else
> #define VMA_UFFD_MINOR EMPTY_VMA_FLAGS
> #endif
> +#ifdef CONFIG_USERFAULTFD_RWP
> +#define VMA_UFFD_RWP mk_vma_flags(VMA_UFFD_RWP_BIT)
> +#else
> +#define VMA_UFFD_RWP EMPTY_VMA_FLAGS
> +#endif
>
> #ifdef CONFIG_64BIT
> #define VM_ALLOW_ANY_UNCACHED INIT_VM_FLAG(ALLOW_ANY_UNCACHED)
> @@ -648,22 +659,24 @@ enum {
> * reconsistuted upon page fault, so necessitate page table copying upon fork.
> *
> * Note that these flags should be compared with the DESTINATION VMA not the
> - * source, as VM_UFFD_WP may not be propagated to destination, while all other
> - * flags will be.
> + * source: VM_UFFD_WP and VM_UFFD_RWP may be cleared on the destination
> + * (dup_userfaultfd() -> userfaultfd_reset_ctx() when the parent context did
> + * not negotiate UFFD_FEATURE_EVENT_FORK), while all other flags propagate.
> *
> * VM_PFNMAP / VM_MIXEDMAP - These contain kernel-mapped data which cannot be
> * reasonably reconstructed on page fault.
> *
> * VM_UFFD_WP - Encodes metadata about an installed uffd
> - * write protect handler, which cannot be
> - * reconstructed on page fault.
> + * VM_UFFD_RWP write- or read-write-protect handler, which
> + * cannot be reconstructed on page fault.
> *
> - * We always copy pgtables when dst_vma has uffd-wp
> - * enabled even if it's file-backed
> - * (e.g. shmem). Because when uffd-wp is enabled,
> - * pgtable contains uffd-wp protection information,
> - * that's something we can't retrieve from page cache,
> - * and skip copying will lose those info.
> + * We always copy pgtables when dst_vma has the
> + * uffd PTE bit in use even if it's file-backed
> + * (e.g. shmem). Because when the uffd bit is
> + * in use, the pgtable contains the protection
> + * information, that's something we can't
> + * retrieve from page cache, and skip copying
> + * will lose those info.
> *
> * VM_MAYBE_GUARD - Could contain page guard region markers which
> * by design are a property of the page tables
> diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> index c4f2cc6dfcf0..f3b2db27989b 100644
> --- a/include/linux/userfaultfd_k.h
> +++ b/include/linux/userfaultfd_k.h
> @@ -21,10 +21,11 @@
> #include <linux/hugetlb_inline.h>
>
> /* The set of all possible UFFD-related VM flags. */
> -#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_WP | VM_UFFD_MINOR)
> +#define __VM_UFFD_FLAGS (VM_UFFD_MISSING | VM_UFFD_MINOR | \
> + VM_UFFD_WP | VM_UFFD_RWP)
>
> #define __VMA_UFFD_FLAGS mk_vma_flags_from_masks(VMA_UFFD_MISSING, VMA_UFFD_WP, \
> - VMA_UFFD_MINOR)
> + VMA_UFFD_MINOR, VMA_UFFD_RWP)
>
> /*
> * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining
> @@ -179,7 +180,8 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
> static inline bool uffd_disable_huge_pmd_share(struct vm_area_struct *vma)
> {
> return vma_test_any_mask(vma,
> - mk_vma_flags_from_masks(VMA_UFFD_WP, VMA_UFFD_MINOR));
> + mk_vma_flags_from_masks(VMA_UFFD_WP, VMA_UFFD_MINOR,
> + VMA_UFFD_RWP));
Wonder if a vma_test_any_masks() is worth adding now :) [will do separately though]
> }
>
> /*
> @@ -210,6 +212,16 @@ static inline bool userfaultfd_minor(struct vm_area_struct *vma)
> return vma_test_any_mask(vma, VMA_UFFD_MINOR);
> }
>
> +static inline bool userfaultfd_rwp(struct vm_area_struct *vma)
> +{
> + return vma_test_any_mask(vma, VMA_UFFD_RWP);
NIT: You could use vma_flags_test_single_mask() just to make it clear it's a single
flag. It's not a big deal though really.
> +}
> +
> +static inline bool userfaultfd_protected(struct vm_area_struct *vma)
> +{
> + return userfaultfd_wp(vma) || userfaultfd_rwp(vma);
> +}
> +
> static inline bool userfaultfd_pte_wp(struct vm_area_struct *vma,
> pte_t pte)
> {
> @@ -330,6 +342,16 @@ static inline bool userfaultfd_minor(struct vm_area_struct *vma)
> return false;
> }
>
> +static inline bool userfaultfd_rwp(struct vm_area_struct *vma)
> +{
> + return false;
> +}
> +
> +static inline bool userfaultfd_protected(struct vm_area_struct *vma)
> +{
> + return false;
> +}
> +
> static inline bool userfaultfd_pte_wp(struct vm_area_struct *vma,
> pte_t pte)
> {
> @@ -423,8 +445,8 @@ static inline bool userfaultfd_wp_use_markers(struct vm_area_struct *vma)
> }
>
> /*
> - * Returns true if this is a swap pte and was uffd-wp wr-protected in either
> - * forms (pte marker or a normal swap pte), false otherwise.
> + * Returns true if this swap pte carries uffd-tracked state in either
> + * form (pte marker or a normal swap pte), false otherwise.
> */
> static inline bool pte_swp_uffd_any(pte_t pte)
> {
> diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
> index a6e5a44c9b42..bfface3d0203 100644
> --- a/include/trace/events/mmflags.h
> +++ b/include/trace/events/mmflags.h
> @@ -194,6 +194,12 @@ IF_HAVE_PG_ARCH_3(arch_3)
> # define IF_HAVE_UFFD_MINOR(flag, name)
> #endif
>
> +#ifdef CONFIG_USERFAULTFD_RWP
> +# define IF_HAVE_UFFD_RWP(flag, name) {flag, name},
> +#else
> +# define IF_HAVE_UFFD_RWP(flag, name)
> +#endif
> +
> #if defined(CONFIG_64BIT) || defined(CONFIG_PPC32)
> # define IF_HAVE_VM_DROPPABLE(flag, name) {flag, name},
> #else
> @@ -215,6 +221,7 @@ IF_HAVE_UFFD_MINOR(VM_UFFD_MINOR, "uffd_minor" ) \
> {VM_PFNMAP, "pfnmap" }, \
> {VM_MAYBE_GUARD, "maybe_guard" }, \
> {VM_UFFD_WP, "uffd_wp" }, \
> +IF_HAVE_UFFD_RWP(VM_UFFD_RWP, "uffd_rwp" ) \
> {VM_LOCKED, "locked" }, \
> {VM_IO, "io" }, \
> {VM_SEQ_READ, "seqread" }, \
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: David Hildenbrand (Arm) @ 2026-06-03 12:27 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe,
Usama Arif, usamaarif642
In-Reply-To: <CAA1CXcD_Bz=Si+vP0Sg_FhAHVjbeAJ4VdvtWGM-jVYiRXFHAnw@mail.gmail.com>
On 6/3/26 14:16, Nico Pache wrote:
> On Wed, Jun 3, 2026 at 4:01 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>>
>>> next_order:
>>> - if ((BIT(order) - 1) & enabled_orders) {
>>> - const u8 next_order = order - 1;
>>> - const u16 mid_offset = offset + (nr_ptes / 2);
>>> -
>>> - collapse_mthp_stack_push(cc, &stack_size, mid_offset,
>>> - next_order);
>>> - collapse_mthp_stack_push(cc, &stack_size, offset,
>>> - next_order);
>>> + if (order > KHUGEPAGED_MIN_MTHP_ORDER &&
>>> + (BIT(order) - 1) & enabled_orders) {
>>
>> Why not a test_bit() ?
>
> The test bit is at the top of the loop. This adds a exit if the lower
> orders are all disabled or we hit the last order.
Ah, now I understand what you want to do here.
I guess you should add a () around the & and maybe add a comment.
And likely using GENMASK is clearer?
/*
* Continue with the next smaller order if there is still
* any smaller order enabled.
*/
if (order > KHUGEPAGED_MIN_MTHP_ORDER &&
(enabled_orders & GENMASK(order - 1, 0))) {
...
}
>
>>
>>
>> But, wouldn't you want to skip orders that are not enabled and try with the next
>> smaller one in any case before you advance the offset?
>
> We are currently iterating through each order (not skipping them).
> There may be optimizations to avoid iterating through every order
> (like your changes suggest), but currently, every collapse, whether it
> succeeds or fails at the bottom order, must also iterate the offset.
Right, we currently miss opportunities to just skip, that we can optimize later.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-06-03 12:16 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe,
Usama Arif, usamaarif642
In-Reply-To: <ef5c470f-3c32-418d-9566-17ec01b691bb@kernel.org>
On Wed, Jun 3, 2026 at 4:01 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>
>
> > next_order:
> > - if ((BIT(order) - 1) & enabled_orders) {
> > - const u8 next_order = order - 1;
> > - const u16 mid_offset = offset + (nr_ptes / 2);
> > -
> > - collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> > - next_order);
> > - collapse_mthp_stack_push(cc, &stack_size, offset,
> > - next_order);
> > + if (order > KHUGEPAGED_MIN_MTHP_ORDER &&
> > + (BIT(order) - 1) & enabled_orders) {
>
> Why not a test_bit() ?
The test bit is at the top of the loop. This adds a exit if the lower
orders are all disabled or we hit the last order.
>
>
> But, wouldn't you want to skip orders that are not enabled and try with the next
> smaller one in any case before you advance the offset?
We are currently iterating through each order (not skipping them).
There may be optimizations to avoid iterating through every order
(like your changes suggest), but currently, every collapse, whether it
succeeds or fails at the bottom order, must also iterate the offset.
lmk if that makes sense!
-- Nico
>
> --
> Cheers,
>
> David
>
^ permalink raw reply
* Re: [PATCH v6 07/13] kho: add support for linked-block serialization
From: Pasha Tatashin @ 2026-06-03 12:05 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, linux-kernel, corbet, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <178046937151.468621.13398573538792303093.b4-review@b4>
On 06-03 09:49, Mike Rapoport wrote:
> On Wed, 03 Jun 2026 03:28:58 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > diff --git a/include/linux/kho/abi/block.h b/include/linux/kho/abi/block.h
> > new file mode 100644
> > index 000000000000..8641c20b379b
> > --- /dev/null
> > +++ b/include/linux/kho/abi/block.h
> > @@ -0,0 +1,56 @@
> > [ ... skip 25 lines ... ]
> > +#define _LINUX_KHO_ABI_BLOCK_H
> > +
> > +#include <asm/page.h>
> > +#include <linux/types.h>
> > +
> > +#define KHO_BLOCK_ABI_COMPATIBLE "kho-block-v1"
>
> It's never used by block set and after looking at the following patches I
> found that it's appended to LUO compatible string.
>
> While this works for LUO, I think it should be kho_block_set_restore()
> responsibility to verify the compatibility.
It should work for any component that relies on kho_block. My proposal
is to use this method for other common KHO data structures (e.g., kho
vmalloc, kho radix, future kho xarray). There is no need for them to
carry the compatibility string in their metadata, as whoever uses them
will include their compatibility string.
For now, reviewers will have to make sure that if the ABI header content
is changed, the compatibility string is updated.
> > diff --git a/kernel/liveupdate/kho_block.c b/kernel/liveupdate/kho_block.c
> > new file mode 100644
> > index 000000000000..4f147c308e6b
> > --- /dev/null
> > +++ b/kernel/liveupdate/kho_block.c
> > @@ -0,0 +1,411 @@
> > [ ... skip 121 lines ... ]
> > +/**
> > + * kho_block_set_grow - Expand the block set to accommodate the target count.
> > + * @bs: The block set.
> > + * @count: The target number of valid entries to accommodate.
> > + *
> > + * Acts as a runtime notifier when new resources (such as files or sessions)
>
> Not sure I understand what "runtime notifier" means in this context.
It came from discussion with Pratyush, but I think we are on the same
page what they are, and I will just remove this.
>
> > [ ... skip 11 lines ... ]
> > +
> > + while (count > bs->nblocks * bs->count_per_block) {
> > + int err = kho_block_set_grow_one(bs);
> > +
> > + if (err)
> > + return err;
>
> This leaks memory if more than one block is added.
>
> > [ ... skip 31 lines ... ]
> > + * unregistered, allowing the block set to release and unallocate redundant
> > + * preserved memory blocks. Checks if the last block in the set can be removed
> > + * because the remaining entry count is fully accommodated by the preceding blocks.
> > + *
> > + * Note: It is the caller's responsibility to ensure that entries are removed
> > + * in LIFO (last-in, first-out) order (the reverse order of their insertion).
>
> I think "in LIFO order" is sufficient :)
Oh, I keep removing those :-)
> > [ ... skip 173 lines ... ]
> > + it->i = 0;
> > + }
> > +
> > + entry = kho_block_entry(it, it->i++);
> > + it->block->ser->count = it->i;
> > + return entry;
>
> This looks way better than the previous version :)
> Thanks!
Thank you. I will send a new version of this patch as a reply to this
email to avoid cluttering the mailing list.
Pasha
>
> --
> Sincerely yours,
> Mike.
>
^ permalink raw reply
* Re: [PATCH v2 2/2] HID: nintendo: Use %pM format specifier for MAC addresses
From: Benjamin Tissoires @ 2026-06-03 12:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Petr Mladek, Tamir Duberstein,
linux-doc, linux-kernel, linux-input, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Andrew Morton
In-Reply-To: <20260603104351.152085-3-andriy.shevchenko@linux.intel.com>
On Jun 03 2026, Andy Shevchenko wrote:
> Convert to %pM instead of using custom code.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Not sure where the first patch should land, so in case someone prefers
having the full series through their tree:
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Cheers,
Benjamin
> ---
> drivers/hid/hid-nintendo.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> index 29008c2cc530..05c50f2530ef 100644
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
> @@ -2431,14 +2431,8 @@ static int joycon_read_info(struct joycon_ctlr *ctlr)
> for (i = 4, j = 0; j < 6; i++, j++)
> ctlr->mac_addr[j] = report->subcmd_reply.data[i];
>
> - ctlr->mac_addr_str = devm_kasprintf(&ctlr->hdev->dev, GFP_KERNEL,
> - "%02X:%02X:%02X:%02X:%02X:%02X",
> - ctlr->mac_addr[0],
> - ctlr->mac_addr[1],
> - ctlr->mac_addr[2],
> - ctlr->mac_addr[3],
> - ctlr->mac_addr[4],
> - ctlr->mac_addr[5]);
> + ctlr->mac_addr_str = devm_kasprintf(&ctlr->hdev->dev, GFP_KERNEL, "%pMU",
> + ctlr->mac_addr);
> if (!ctlr->mac_addr_str)
> return -ENOMEM;
> hid_info(ctlr->hdev, "controller MAC = %s\n", ctlr->mac_addr_str);
> --
> 2.50.1
>
>
^ permalink raw reply
* [PATCH] Documentation: KVM: Synchronize x86 VM types
From: Carlos López @ 2026-06-03 11:45 UTC (permalink / raw)
To: kvm, linux-doc, linux-kernel
Cc: Carlos López, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Ashish Kalra, Michael Roth, Brijesh Singh, Isaku Yamahata,
Binbin Wu
KVM has reflected KVM_X86_SNP_VM to userspace since 1dfe571c12cf
("KVM: SEV: Add initial SEV-SNP support"), and KVM_X86_TDX_VM since
161d34609f9b ("KVM: TDX: Make TDX VM type supported"). Update the
documentation to reflect this fact.
Fixes: 1dfe571c12cf ("KVM: SEV: Add initial SEV-SNP support")
Fixes: 161d34609f9b ("KVM: TDX: Make TDX VM type supported")
Signed-off-by: Carlos López <clopez@suse.de>
---
Documentation/virt/kvm/api.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 52bbbb553ce1..3ec574a41f60 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -9363,6 +9363,8 @@ means the VM type with value @n is supported. Possible values of @n are::
#define KVM_X86_SW_PROTECTED_VM 1
#define KVM_X86_SEV_VM 2
#define KVM_X86_SEV_ES_VM 3
+ #define KVM_X86_SNP_VM 4
+ #define KVM_X86_TDX_VM 5
Note, KVM_X86_SW_PROTECTED_VM is currently only for development and testing.
Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, and especially not in
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3 3/4] mm/zswap: Add per-memcg stat for proactive writeback
From: Hao Jia @ 2026-06-03 11:29 UTC (permalink / raw)
To: Nhat Pham
Cc: akpm, tj, hannes, shakeel.butt, mhocko, yosry, mkoutny,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <CAKEwX=PcFqmsdFqUnpWxrPkoc1B-1w3CEb0ydK3df0qJGG-mnQ@mail.gmail.com>
On 2026/5/30 04:01, Nhat Pham wrote:
> On Tue, May 26, 2026 at 4:46 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>>
>> From: Hao Jia <jiahao1@lixiang.com>
>>
>> Currently, zswap writeback can be triggered by either the pool limit
>> being hit or by the proactive writeback mechanism. However, the
>> existing 'zswpwb' metric in memory.stat and /proc/vmstat counts all
>> written back pages, making it difficult to distinguish between pages
>> written back due to the pool limit and those written back proactively.
>>
>> Add a new statistic 'zswpwb_proactive' to memory.stat and /proc/vmstat.
>> This counter tracks the number of pages written back due to proactive
>> writeback. This allows users to better monitor and tune the proactive
>> writeback mechanism.
>>
>> Signed-off-by: Hao Jia <jiahao1@lixiang.com>
>> ---
>> Documentation/admin-guide/cgroup-v2.rst | 4 +++
>> include/linux/vm_event_item.h | 1 +
>> mm/memcontrol.c | 1 +
>> mm/vmstat.c | 1 +
>> mm/zswap.c | 41 ++++++++++++++++++-------
>> 5 files changed, 37 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index 6564abf0dec5..7d65aef83f7b 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -1748,6 +1748,10 @@ The following nested keys are defined.
>> zswpwb
>> Number of pages written from zswap to swap.
>>
>> + zswpwb_proactive
>> + Number of pages written from zswap to swap by proactive
>> + writeback. This is a subset of zswpwb.
>> +
>
> nit: I think this is specifically the zswap_writeback_only mode right?
>
> Technically, normal proactive reclaim (memory.reclaim) can also hit zswap :)
>
> Maybe some clarification here?
Thanks for the review. I will clarify this further in the next version.
Thanks,
Hao
^ permalink raw reply
* Re: [PATCH v2 05/18] perf test: Add deterministic workload
From: Leo Yan @ 2026-06-03 11:27 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260602-james-cs-context-tracking-fix-v2-5-85b5ce6f55c6@linaro.org>
On Tue, Jun 02, 2026 at 03:26:47PM +0100, James Clark wrote:
[...]
> @@ -22,3 +23,4 @@ CFLAGS_brstack.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> CFLAGS_datasym.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> CFLAGS_traploop.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> CFLAGS_inlineloop.o = -g -O2
> +CFLAGS_deterministic.o = -g -O0
I have no strong opinion for using 'noinline' in source or using the
global option '-fno-inline', just thought this is not easy to follow
up if anyone (likely myself) will write a new workload for disabling
inline. Could we have consistent style for this?
For the patch itself:
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: Hao Jia @ 2026-06-03 11:27 UTC (permalink / raw)
To: Yosry Ahmed
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <aho-Z6wshceTAYd9@google.com>
On 2026/5/30 09:37, Yosry Ahmed wrote:
> On Tue, May 26, 2026 at 07:45:59PM +0800, Hao Jia wrote:
>> From: Hao Jia <jiahao1@lixiang.com>
>>
>> Zswap currently writes back pages to backing swap reactively, triggered
>> either by the shrinker or when the pool reaches its size limit. There is
>> no mechanism to control the amount of writeback for a specific memory
>> cgroup. However, users may want to proactively write back zswap pages,
>> e.g., to free up memory for other applications or to prepare for
>> memory-intensive workloads.
>>
>> Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup
>> interface. When specified, this key bypasses standard memory reclaim
>> and exclusively performs proactive zswap writeback up to the requested
>> budget. If omitted, the default reclaim behavior remains unchanged.
>>
>> Example usage:
>> # Write back 100MB of pages from zswap to the backing swap
>> echo "100M zswap_writeback_only" > memory.reclaim
>>
>> Note that the actual amount written back may be less than requested due
>> to the zswap second-chance algorithm: referenced entries are rotated on
>> the LRU on the first encounter and only written back on a second pass.
>> If fewer bytes are written back than requested, -EAGAIN is returned,
>> matching the existing memory.reclaim semantics.
>>
>> Internally, extend user_proactive_reclaim() to parse the new
>> "zswap_writeback_only" token and invoke the dedicated handler. Add
>> zswap_proactive_writeback() to walk the target memcg subtree via the
>> per-memcg writeback cursor, draining per-node zswap LRUs through
>> list_lru_walk_one() with the shrink_memcg_cb() callback.
>>
>> Suggested-by: Yosry Ahmed <yosry@kernel.org>
>> Suggested-by: Nhat Pham <nphamcs@gmail.com>
>> Signed-off-by: Hao Jia <jiahao1@lixiang.com>
>> ---
>> Documentation/admin-guide/cgroup-v2.rst | 18 +++-
>> Documentation/admin-guide/mm/zswap.rst | 11 +-
>> include/linux/zswap.h | 7 ++
>> mm/vmscan.c | 14 +++
>> mm/zswap.c | 138 ++++++++++++++++++++++++
>> 5 files changed, 185 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index 6efd0095ed99..6564abf0dec5 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -1425,9 +1425,10 @@ PAGE_SIZE multiple when read back.
>>
>> The following nested keys are defined.
>>
>> - ========== ================================
>> + ==================== ==================================================
>> swappiness Swappiness value to reclaim with
>> - ========== ================================
>> + zswap_writeback_only Only perform proactive zswap writeback
>> + ==================== ==================================================
>>
>> Specifying a swappiness value instructs the kernel to perform
>> the reclaim with that swappiness value. Note that this has the
>> @@ -1437,6 +1438,19 @@ The following nested keys are defined.
>> The valid range for swappiness is [0-200, max], setting
>> swappiness=max exclusively reclaims anonymous memory.
>>
>> + The zswap_writeback_only key skips ordinary memory reclaim and
>> + writes back pages from zswap to the backing swap device until
>> + the requested amount has been written or no further candidates
>> + are found. This is useful to proactively offload cold pages from
>> + the zswap pool to the swap device. It is only available if
>> + zswap writeback is enabled. zswap_writeback_only cannot be combined
>> + with swappiness; specifying both returns -EINVAL.
>> +
>> + Example::
>> +
>> + # Write back up to 100MB of pages from zswap to the backing swap
>> + echo "100M zswap_writeback_only" > memory.reclaim
>
>
> memcg folks need to chime in about the interface here. An alternative
> would be a separate interface (e.g. memory.zswap.do_writeback or
> memory.zswap.writeback.reclaim or sth).
>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> index 73e64a635690..7bcbf788f634 100644
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -1679,6 +1679,144 @@ int zswap_load(struct folio *folio)
>> return 0;
>> }
>>
>> +/*
>> + * Maximum LRU scan limit:
>> + * number of entries to scan per page of remaining budget.
>> + */
>> +#define ZSWAP_PROACTIVE_WB_SCAN_RATIO 16UL
>> +/*
>> + * Batch size for proactive writeback:
>> + * - As the per-memcg writeback target in the outer memcg loop.
>> + * - As the per-walk budget passed to list_lru_walk_one().
>> + */
>> +#define ZSWAP_PROACTIVE_WB_BATCH 128UL
>> +
>> +/*
>> + * Walk the per-node LRUs of @memcg to write back up to @nr_to_write pages.
>> + * Returns the number of pages written back, or -ENOENT if @memcg is a
>> + * zombie or has writeback disabled.
>> + */
>> +static long zswap_proactive_shrink_memcg(struct mem_cgroup *memcg,
>> + unsigned long nr_to_write)
>> +{
>> + unsigned long nr_written = 0;
>> + int nid;
>> +
>> + if (!mem_cgroup_zswap_writeback_enabled(memcg))
>> + return -ENOENT;
>> +
>> + if (!mem_cgroup_online(memcg))
>> + return -ENOENT;
>> +
>> + for_each_node_state(nid, N_NORMAL_MEMORY) {
>> + bool encountered_page_in_swapcache = false;
>> + unsigned long nr_to_scan, nr_scanned = 0;
>> +
>> + /*
>> + * Cap by LRU length: bounds rewalks when referenced
>> + * entries keep rotating to the tail.
>> + */
>> + nr_to_scan = list_lru_count_one(&zswap_list_lru, nid, memcg);
>> + if (!nr_to_scan)
>> + continue;
>> +
>> + /*
>> + * Cap by SCAN_RATIO * remaining budget: bounds scan cost
>> + * to the remaining writeback budget.
>> + */
>> + nr_to_scan = min(nr_to_scan,
>> + (nr_to_write - nr_written) * ZSWAP_PROACTIVE_WB_SCAN_RATIO);
>> +
>> + while (nr_scanned < nr_to_scan) {
>> + unsigned long nr_to_walk = min(ZSWAP_PROACTIVE_WB_BATCH,
>> + nr_to_scan - nr_scanned);
>> +
>> + if (signal_pending(current))
>> + return nr_written;
>> +
>> + /*
>> + * Account for the committed budget rather than the walker's
>> + * actual delta. If the list is emptied concurrently, the
>> + * walker visits nothing and nr_scanned would never advance.
>> + */
>> + nr_scanned += nr_to_walk;
>> +
>> + nr_written += list_lru_walk_one(&zswap_list_lru, nid, memcg,
>> + &shrink_memcg_cb,
>> + &encountered_page_in_swapcache,
>> + &nr_to_walk);
>> +
>> + if (nr_written >= nr_to_write)
>> + return nr_written;
>> + if (encountered_page_in_swapcache)
>> + break;
>> +
>> + cond_resched();
>> + }
>> + }
>> +
>> + return nr_written;
>> +}
>> +
>> +int zswap_proactive_writeback(struct mem_cgroup *memcg,
>> + unsigned long nr_to_writeback)
>> +{
>> + struct mem_cgroup *iter_memcg;
>> + unsigned long nr_written = 0;
>> + int failures = 0, attempts = 0;
>> +
>> + if (!memcg)
>> + return -EINVAL;
>> + if (!nr_to_writeback)
>> + return 0;
>> +
>> + /*
>> + * Writeback will be aborted with -EAGAIN if we encounter
>> + * the following MAX_RECLAIM_RETRIES times:
>> + * - No writeback-candidate memcgs found in a subtree walk.
>> + * - A writeback-candidate memcg wrote back zero pages.
>> + */
>> + while (nr_written < nr_to_writeback) {
>> + unsigned long batch_size;
>> + long shrunk;
>> +
>> + if (signal_pending(current))
>> + return -EINTR;
>> +
>> + iter_memcg = zswap_mem_cgroup_iter(memcg);
>> +
>> + if (!iter_memcg) {
>> + /*
>> + * Continue without incrementing failures if we found
>> + * candidate memcgs in the last subtree walk.
>> + */
>> + if (!attempts && ++failures == MAX_RECLAIM_RETRIES)
>> + return -EAGAIN;
>> + attempts = 0;
>> + continue;
>> + }
>> +
>> + batch_size = min(nr_to_writeback - nr_written,
>> + ZSWAP_PROACTIVE_WB_BATCH);
>> + shrunk = zswap_proactive_shrink_memcg(iter_memcg, batch_size);
>> + mem_cgroup_put(iter_memcg);
>> +
>> + /* Writeback-disabled or offline: skip without counting. */
>> + if (shrunk == -ENOENT)
>> + continue;
>> +
>> + ++attempts;
>> + if (shrunk > 0)
>> + nr_written += shrunk;
>> + else if (++failures == MAX_RECLAIM_RETRIES)
>> + return -EAGAIN;
>> +
>> + cond_resched();
>> + }
>> +
>> + return 0;
>> +}
>> +
>
> There is a lot of copy+paste from shrink_worker() and shrink_memcg()
> here. We really should be able to reuse shrink_memcg().
>
I will do some consolidation and code reuse in the next version.
> Is the main difference that we are scanning in batches here? I think we
> can have shrink_memcg() do that too. If anything, it might make the
> shrinker more efficient. Over-reclaim is ofc a concern, and especially
> in the zswap_store() path as the overhead can be noticeable. Maybe we
> can parameterize the batch size based on the code path.
>
> Nhat, what do you think?
Nhat, since we now have the referenced-based second chance algorithm,
should we consider doing batch writeback for shrink_memcg() as well?
Of course, we could pass a parameter to control whether batch writeback
is needed, so as to preserve the original behavior of shrink_memcg().
Thanks,
Hao
^ permalink raw reply
* Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: Hao Jia @ 2026-06-03 11:22 UTC (permalink / raw)
To: Yosry Ahmed, Nhat Pham
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, chengming.zhou,
muchun.song, roman.gushchin, cgroups, linux-mm, linux-kernel,
linux-doc, Hao Jia
In-Reply-To: <aho_VtLCmIRsNyvO@google.com>
On 2026/5/30 09:40, Yosry Ahmed wrote:
> On Fri, May 29, 2026 at 12:58:09PM -0700, Nhat Pham wrote:
>> On Tue, May 26, 2026 at 4:46 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>>>
>>> From: Hao Jia <jiahao1@lixiang.com>
>>>
>>> Zswap currently writes back pages to backing swap reactively, triggered
>>> either by the shrinker or when the pool reaches its size limit. There is
>>> no mechanism to control the amount of writeback for a specific memory
>>> cgroup. However, users may want to proactively write back zswap pages,
>>> e.g., to free up memory for other applications or to prepare for
>>> memory-intensive workloads.
>>>
>>> Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup
>>> interface. When specified, this key bypasses standard memory reclaim
>>> and exclusively performs proactive zswap writeback up to the requested
>>> budget. If omitted, the default reclaim behavior remains unchanged.
>>>
>>> Example usage:
>>> # Write back 100MB of pages from zswap to the backing swap
>>> echo "100M zswap_writeback_only" > memory.reclaim
>>
>> Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB
>> compresses to 25 MB, then you're only freeing 25 MB?
>>
>> I'm ok-ish with this, but can you document it?
>
> That's a good point. I think pre-compressed size doesn't make sense to
> be honest. We should care about how much memory we are actually trying
> to save by doing writeback here.
>
> The pre-compressed size is only useful in determining the blast radius,
> how many actual pages are going to have slower page faults now. But
> then, I don't think there's a reasonable way for userspace to decide
> that.
>
> I understand passing in the compressed size is tricky because we need to
> keep track of the size of the compressed pages we end up writing back,
> but it should be doable.
Agreed. Using pre-compressed size is probably easier to implement. IIRC,
interfaces like ZRAM writeback_limit are also calculated using the
pre-compressed size.
I'll clarify this in the documentation in the next version.
>
> If we really want pre-compressed size here, then yes we need to make it
> very clear, and I vote that we use a separate interface in this case
> because memory.reclaim having different meanings for the amount of
> memory written to it is extremely counter-intuitive.
>
Agree. This would indeed break the semantics of memory.reclaim. I will
use a separate interface for proactive writeback in the next version.
Thanks，
Hao
>>
>> The rest seems solid to me, FWIW. I'll defer to Johannes and Yosry for
>> opinions on zswap-only proactive reclaim.
^ permalink raw reply
* Re: [PATCH] Documentation: drm: Add entry for removing spsc_queue to TODO list
From: Philipp Stanner @ 2026-06-03 11:14 UTC (permalink / raw)
To: Christian König, Philipp Stanner, avid Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, dakr, Tvrtko Ursulin
Cc: dri-devel, linux-doc, linux-kernel
In-Reply-To: <aceb688b-4f65-4539-a4f1-fc5455b60a5f@amd.com>
On Mon, 2026-06-01 at 10:30 +0200, Christian König wrote:
>
>
> On 5/29/26 23:52, Philipp Stanner wrote:
> > drm_sched contains a lockless queue (spsc_queue) that seems to be
> > useless and potentially unsound.
> >
> > Add a TODO list entry for replacing spsc_queue with a locked list.
> >
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
>
> Reviewed-by: Christian König <christian.koenig@amd.com>
Pushed to drm-misc-next
Thx
P.
>
> > ---
> > Documentation/gpu/todo.rst | 41 ++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index cdddf8db35f5..87e082b0eb48 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -948,6 +948,47 @@ Contact: Philipp Stanner <phasta@kernel.org>
> >
> > Level: Intermediate
> >
> > +Replace the lockless queue with a locked list
> > +---------------------------------------------
> > +
> > +drm_sched is the only user in the entire kernel of a special lockless queue, the
> > +spsc_queue. This queue utilizes:
> > +
> > +- preempt_disable()
> > +- atomic instructions
> > +- memory barriers
> > +- ACCESS_ONCE()
> > +
> > +whereas a conventional spinlock utilizes:
> > +
> > +- preempt_disable()
> > +- 1 atomic instruction for taking / releasing the lock
> > +- memory barriers
> > +
> > +Moreover, drm_sched_entity_push_job(), the only user of spsc_queue_push(), has
> > +to take a lock in some situations anyways and calls to it are often serialized
> > +with a driver lock.
> > +
> > +It is, thus, highly questionable whether the lockless queue grants any advantage
> > +at all. Considering that its internals are not well documented and its correctness
> > +is not formally proven, it seems desirable to replace the queue with a mere list
> > +or hlist that is protected by a spinlock.
> > +
> > +Tasks:
> > +
> > +- Replace the spsc_queue in drm/sched (and those who might access the scheduler's
> > + internal queue) with a spinlock + (h)list.
> > +- Ideally, check with some micro benchmarks and real world tests (preferably
> > + with amdgpu) for relevant performance regressions.
> > +- Remove the spsc_queue from the kernel altogether.
> > +
> > +Contact:
> > +
> > +- Philipp Stanner <phasta@kernel.org>
> > +- Christian König <christian.koenig@amd.com>
> > +
> > +Level: Beginner
> > +
> > Outside DRM
> > ===========
> >
^ permalink raw reply
* Re: [PATCH v2 04/18] perf test cs-etm: Test process attribution
From: James Clark @ 2026-06-03 11:20 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260603111018.GS101133@e132581.arm.com>
On 03/06/2026 12:10 pm, Leo Yan wrote:
> On Tue, Jun 02, 2026 at 03:26:46PM +0100, James Clark wrote:
>
> [...]
>
>> +check_samples() {
>> + owner_samples=$(grep -c "proc1.*context_switch_loop_proc1" "$tmpdir/script" || true)
>> + next_samples=$(grep -c "proc2.*context_switch_loop_proc2" "$tmpdir/script" || true)
>> +
>> + if [ "$owner_samples" -eq 0 ] || [ "$next_samples" -eq 0 ]; then
>> + echo "No samples found"
>> + cleanup
>
> We don't need cleanup explictly here, as trap covers exit case?
>
We need it whenever we call exit because it removes the trap which would
trap and return with its own (potentially different) exit value.
The alternative is a global $err which you set and then call exit
without a value and let cleanup() do exit $err. But from searching the
existing shell tests calling cleanup before exit seemed to be more
common so I did it that way.
>> + exit 1
>> + fi
>> +
>> + if grep "proc2.*context_switch_loop_proc1" "$tmpdir/script"; then
>> + echo "Thread1 symbol was attributed to proc2"
>> + cleanup
>
> Ditto.
>
>> + exit 1
>> + fi
>> +
>> + if grep "proc1.*context_switch_loop_proc2" "$tmpdir/script"; then
>> + echo "Thread2 symbol was attributed to proc1"
>> + cleanup
>
> Ditto.
>
> Otherwise:
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH v2 03/18] perf test: Add a workload that forces context switches
From: James Clark @ 2026-06-03 11:17 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260603110621.GR101133@e132581.arm.com>
On 03/06/2026 12:06 pm, Leo Yan wrote:
> On Tue, Jun 02, 2026 at 03:26:45PM +0100, James Clark wrote:
>
> [...]
>
>> +/* Not static to avoid LTO clobbering the function name */
>> +void context_switch_loop_proc1(int in_fd, int out_fd);
>> +noinline void context_switch_loop_proc1(int in_fd, int out_fd)
>> +{
>> + for (int i = 0; i < loops; i++) {
>> + read_block(in_fd);
>> + context_switch_loop_work += i * 3;
>> + write_block(out_fd);
>> + }
>> +}
>
> Rather than struggling with unexpected options, and "noinline" might
> not work as it is not a standard compiler option (it is defined in
> kernel header as AI reminded me), wouldn't it is reliable to use a
> dedicated CFLAG rule same as other programs?
>
> Thanks,
> Leo
noinline seems to be used as standard across the tools codebase, so if
it doesn't work there are bigger problems. Perf also only really seems
to support GCC and Clang and they both work for this test.
And I don't actually think it matters if this is inlined or not as long
as the debug info reports those lines as being in this function. That's
what what having it as a global symbol is supposed to achieve, but
that's about renaming rather than inlining. Maybe inline is over the
top, but its a pattern copied from other similar workloads and tests.
Probably makes sense to wait for an actual failure to appear and then we
can decide what to do with it then.
^ permalink raw reply
* Re: [PATCH v2 04/18] perf test cs-etm: Test process attribution
From: Leo Yan @ 2026-06-03 11:10 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260602-james-cs-context-tracking-fix-v2-4-85b5ce6f55c6@linaro.org>
On Tue, Jun 02, 2026 at 03:26:46PM +0100, James Clark wrote:
[...]
> +check_samples() {
> + owner_samples=$(grep -c "proc1.*context_switch_loop_proc1" "$tmpdir/script" || true)
> + next_samples=$(grep -c "proc2.*context_switch_loop_proc2" "$tmpdir/script" || true)
> +
> + if [ "$owner_samples" -eq 0 ] || [ "$next_samples" -eq 0 ]; then
> + echo "No samples found"
> + cleanup
We don't need cleanup explictly here, as trap covers exit case?
> + exit 1
> + fi
> +
> + if grep "proc2.*context_switch_loop_proc1" "$tmpdir/script"; then
> + echo "Thread1 symbol was attributed to proc2"
> + cleanup
Ditto.
> + exit 1
> + fi
> +
> + if grep "proc1.*context_switch_loop_proc2" "$tmpdir/script"; then
> + echo "Thread2 symbol was attributed to proc1"
> + cleanup
Ditto.
Otherwise:
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH] Documentation: index.rst: add entry of other sub-directory
From: Sebastian Andrzej Siewior @ 2026-06-03 11:06 UTC (permalink / raw)
To: Manuel Ebner
Cc: linux-rt-users, Clark Williams, Steven Rostedt, Jonathan Corbet,
Shuah Khan, open list:Real-time Linux (PREEMPT_RT),
open list:DOCUMENTATION, open list
In-Reply-To: <a553f123de4b4887e8e78e751ca727f9992d8b00.camel@mailbox.org>
On 2026-06-03 12:55:57 [+0200], Manuel Ebner wrote:
> > People have been complaining about this
>
> Maybe with the help of them we can figure out what's happening.
> adding linux-rt-user@vger.kernel.org
good luck. What I managed to find out is that those, that did not copy
statements but run into trouble themself, were using in a multi-CPU
scenario. Based on other details I *think* it should not happen single
CPU usage but nobody confirmed.
But this HCBS thingy aims at replacing/ removing it entirely…
Sebastian
^ permalink raw reply
* Re: [PATCH v2 03/18] perf test: Add a workload that forces context switches
From: Leo Yan @ 2026-06-03 11:06 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260602-james-cs-context-tracking-fix-v2-3-85b5ce6f55c6@linaro.org>
On Tue, Jun 02, 2026 at 03:26:45PM +0100, James Clark wrote:
[...]
> +/* Not static to avoid LTO clobbering the function name */
> +void context_switch_loop_proc1(int in_fd, int out_fd);
> +noinline void context_switch_loop_proc1(int in_fd, int out_fd)
> +{
> + for (int i = 0; i < loops; i++) {
> + read_block(in_fd);
> + context_switch_loop_work += i * 3;
> + write_block(out_fd);
> + }
> +}
Rather than struggling with unexpected options, and "noinline" might
not work as it is not a standard compiler option (it is defined in
kernel header as AI reminded me), wouldn't it is reliable to use a
dedicated CFLAG rule same as other programs?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH] Documentation: index.rst: add entry of other sub-directory
From: Manuel Ebner @ 2026-06-03 10:55 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-rt-users
Cc: Clark Williams, Steven Rostedt, Jonathan Corbet, Shuah Khan,
open list:Real-time Linux (PREEMPT_RT), open list:DOCUMENTATION,
open list
In-Reply-To: <20260603102020.ZsS16TaP@linutronix.de>
On Wed, 2026-06-03 at 12:20 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-06-03 10:04:31 [+0200], Manuel Ebner wrote:
> > add reference to scheduler/sched-rt-group.rst
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > Documentation/core-api/real-time/index.rst | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/core-api/real-time/index.rst b/Documentation/core-api/real-
> > time/index.rst
> > index f08d2395a22c..661b419e7f8f 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
> > + Real-Time group scheduling <../../scheduler/sched-rt-group>
>
> Have you been using this and are referencing this because it is useful
> or did you just happen to find it?
I happened to find it.
> People have been complaining about this
Maybe with the help of them we can figure out what's happening.
adding linux-rt-user@vger.kernel.org
> and I *think* it fails to work
> in multi-CPU scenarios (it might work if the task is restricted to
> single CPU usage). Not entirely certain. But complains, that I am
> certain of.
> There is replacement underway to utilize SCHED_DL for this as in
> "Hierarchical Constant Bandwidth Server (HCBS)"
> https://lore.kernel.org/all/20260430213835.62217-1-yurand2000@gmail.com/
will look into this.
>
> Sebastian
Thanks for the feedback
Manuel
^ permalink raw reply
* Re: [PATCH v2 02/18] perf test: Add workload-ctl option
From: Leo Yan @ 2026-06-03 10:50 UTC (permalink / raw)
To: James Clark, Mike Leach, Arnaldo Carvalho de Melo, Namhyung Kim,
Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet, Shuah Khan,
Paschalis Mpeis, coresight, linux-perf-users, linux-kernel,
Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260603104001.GP101133@e132581.arm.com>
On Wed, Jun 03, 2026 at 11:40:01AM +0100, Coresight ML wrote:
> On Tue, Jun 02, 2026 at 03:26:44PM +0100, James Clark wrote:
>
> [...]
>
> > --- a/tools/perf/Documentation/perf-test.txt
> > +++ b/tools/perf/Documentation/perf-test.txt
> > @@ -69,3 +69,9 @@ OPTIONS
> >
> > --list-workloads::
> > List the available workloads to use with -w/--workload.
> > +
> > +--workload-ctl=fifo:ctl-fifo[,ack-fifo]::
> > + Write 'enable' to ctl-fifo before running the workload and 'disable'
> > + before returning. If ack-fifo is provided, the workload runner waits for
> > + an 'ack' response after each command. This scopes the recording to only
> > + the workload if used with 'perf record -D 1 --control ...'.
>
> This new option doesn't work on its own. I would spell out in explicit
> words that it needs to communicate with perf record session:
>
> "This option is used to communicate with a perf record session in
> order to control the recording scope. When specifying this option,
> the same FIFO path must be specified in the record session via:
>
> perf record -D 1 --control=fifo:ctl-fifo[,ack-fifo] ...
Correct typo: s/-D 1/-D -1/
^ permalink raw reply
* Re: [PATCH v2 02/18] perf test: Add workload-ctl option
From: James Clark @ 2026-06-03 10:46 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260603104001.GP101133@e132581.arm.com>
On 03/06/2026 11:40 am, Leo Yan wrote:
> On Tue, Jun 02, 2026 at 03:26:44PM +0100, James Clark wrote:
>
> [...]
>
>> --- a/tools/perf/Documentation/perf-test.txt
>> +++ b/tools/perf/Documentation/perf-test.txt
>> @@ -69,3 +69,9 @@ OPTIONS
>>
>> --list-workloads::
>> List the available workloads to use with -w/--workload.
>> +
>> +--workload-ctl=fifo:ctl-fifo[,ack-fifo]::
>> + Write 'enable' to ctl-fifo before running the workload and 'disable'
>> + before returning. If ack-fifo is provided, the workload runner waits for
>> + an 'ack' response after each command. This scopes the recording to only
>> + the workload if used with 'perf record -D 1 --control ...'.
>
> This new option doesn't work on its own. I would spell out in explicit
> words that it needs to communicate with perf record session:
>
> "This option is used to communicate with a perf record session in
> order to control the recording scope. When specifying this option,
> the same FIFO path must be specified in the record session via:
>
> perf record -D 1 --control=fifo:ctl-fifo[,ack-fifo] ...
>
> The perf test sends 'enable' and 'disable' commands through ctl-fifo to
> control event recording. If 'ack-fifo' is provided, the workload runner
> waits for an 'ack' response after each command."
>
> BTW, I'd say the naming "--record-ctl" might be more close to the
> purpose.
>
Will do
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH v15 02/12] lib: kstrtox: add local _parse_integer_limit_init() helper
From: Rodrigo Alencar @ 2026-06-03 10:45 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky,
Shuah Khan
In-Reply-To: <aiAEmS7aa5p1Fi7g@ashevche-desk.local>
On 26/06/03 01:40PM, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 11:27:11AM +0100, Rodrigo Alencar wrote:
> > On 26/06/02 10:43PM, Andy Shevchenko wrote:
> > > On Sun, May 31, 2026 at 09:30:45AM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > +static unsigned int _parse_integer_limit_init(const char *s, unsigned int base,
> > > > + unsigned long long init,
> > >
> > > Why not name it res...
> >
> > "res" is short for result and this is an init value. I suppose the compiler
> > can optmize towards that kinda of efficiency. I thought of "p" itself to
> > carry the init value, and the function would just accumulate, but that would
> > change expectations on the function behavior.
>
> > > > + unsigned long long *p,
> > > > + size_t max_chars)
>
> In any case I hope you saw my mini-series:
> 20260602203706.103449-1-andriy.shevchenko@linux.intel.com
I did. It looks good and it fits well here. Although I suppose that would delay
this one bit more.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* [PATCH v2 1/2] vsprintf: Add upper case flavour to %p[mM]
From: Andy Shevchenko @ 2026-06-03 10:34 UTC (permalink / raw)
To: Andy Shevchenko, Jiri Kosina, Daniel J. Ogorchock, Petr Mladek,
Tamir Duberstein, linux-doc, linux-kernel, linux-input
Cc: Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky,
Jonathan Corbet, Shuah Khan, Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
Some of the (ABI aware) code needs an upper case when printing MAC
addresses. Introduce an extension for that into the existing %p[mM].
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Documentation/core-api/printk-formats.rst | 3 +++
lib/tests/printf_kunit.c | 2 ++
lib/vsprintf.c | 22 ++++++++++++++++------
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index c0b1b6089307..57e887ff24bc 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -322,6 +322,7 @@ MAC/FDDI addresses
%pMF 00-01-02-03-04-05
%pm 000102030405
%pmR 050403020100
+ %p[mM][FR][U]
For printing 6-byte MAC/FDDI addresses in hex notation. The ``M`` and ``m``
specifiers result in a printed address with (M) or without (m) byte
@@ -335,6 +336,8 @@ For Bluetooth addresses the ``R`` specifier shall be used after the ``M``
specifier to use reversed byte order suitable for visual interpretation
of Bluetooth addresses which are in the little endian order.
+When ``U`` is passed, the result is printed in the upper case.
+
Passed by reference.
IPv4 addresses
diff --git a/lib/tests/printf_kunit.c b/lib/tests/printf_kunit.c
index 58e639b01e83..eccf041ebd56 100644
--- a/lib/tests/printf_kunit.c
+++ b/lib/tests/printf_kunit.c
@@ -435,8 +435,10 @@ mac(struct kunit *kunittest)
test("2d:48:d6:fc:7a:05", "%pM", addr);
test("05:7a:fc:d6:48:2d", "%pMR", addr);
+ test("05:7A:FC:D6:48:2D", "%pMRU", addr);
test("2d-48-d6-fc-7a-05", "%pMF", addr);
test("2d48d6fc7a05", "%pm", addr);
+ test("2D48D6FC7A05", "%pmU", addr);
test("057afcd6482d", "%pmR", addr);
}
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 1389b50266bf..c9b6ec0f0de6 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1303,31 +1303,39 @@ char *mac_address_string(char *buf, char *end, u8 *addr,
char mac_addr[sizeof("xx:xx:xx:xx:xx:xx")];
char *p = mac_addr;
int i;
- char separator;
+ char separator = ':';
bool reversed = false;
+ bool uc = false;
if (check_pointer(&buf, end, addr, spec))
return buf;
switch (fmt[1]) {
case 'F':
+ uc = fmt[2] == 'U';
separator = '-';
break;
case 'R':
+ uc = fmt[2] == 'U';
reversed = true;
- fallthrough;
+ break;
+
+ case 'U':
+ uc = true;
+ break;
default:
- separator = ':';
break;
}
for (i = 0; i < 6; i++) {
- if (reversed)
- p = hex_byte_pack(p, addr[5 - i]);
+ u8 byte = reversed ? addr[5 - i] : addr[i];
+
+ if (uc)
+ p = hex_byte_pack_upper(p, byte);
else
- p = hex_byte_pack(p, addr[i]);
+ p = hex_byte_pack(p, byte);
if (fmt[0] == 'M' && i != 5)
*p++ = separator;
@@ -2410,6 +2418,7 @@ early_param("no_hash_pointers", no_hash_pointers_enable);
* - 'MF' For a 6-byte MAC FDDI address, it prints the address
* with a dash-separated hex notation
* - '[mM]R' For a 6-byte MAC address, Reverse order (Bluetooth)
+ * - '[mM][FR][U]' One of the above in the upper case
* - 'I' [46] for IPv4/IPv6 addresses printed in the usual way
* IPv4 uses dot-separated decimal without leading 0's (1.2.3.4)
* IPv6 uses colon separated network-order 16 bit hex with leading 0's
@@ -2544,6 +2553,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
case 'm': /* Contiguous: 000102030405 */
/* [mM]F (FDDI) */
/* [mM]R (Reverse order; Bluetooth) */
+ /* [mM][FR][U] (One of the above in the upper case) */
return mac_address_string(buf, end, ptr, spec, fmt);
case 'I': /* Formatted IP supported
* 4: 1.2.3.4
--
2.50.1
^ permalink raw reply related
* [PATCH v2 0/2] vsprintf: add upper case to %p[mM] et alia
From: Andy Shevchenko @ 2026-06-03 10:34 UTC (permalink / raw)
To: Andy Shevchenko, Jiri Kosina, Daniel J. Ogorchock, Petr Mladek,
Tamir Duberstein, linux-doc, linux-kernel, linux-input
Cc: Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky,
Jonathan Corbet, Shuah Khan, Benjamin Tissoires, Andrew Morton
The first patch induced by Sashiko rightfully rises a concern on
potential ABI breakage. To avoid that and allow the user (patch 2)
to be converted to use unified output introduce %p[mM][...]U for
printing in upper case. Tests are included and passed.
Changelog v2:
- added first patch (Sashiko)
Andy Shevchenko (2):
vsprintf: Add upper case flavour to %p[mM]
HID: nintendo: Use %pM format specifier for MAC addresses
Documentation/core-api/printk-formats.rst | 3 +++
drivers/hid/hid-nintendo.c | 10 ++--------
lib/tests/printf_kunit.c | 2 ++
lib/vsprintf.c | 22 ++++++++++++++++------
4 files changed, 23 insertions(+), 14 deletions(-)
--
2.50.1
^ permalink raw reply
* [PATCH v2 2/2] HID: nintendo: Use %pM format specifier for MAC addresses
From: Andy Shevchenko @ 2026-06-03 10:34 UTC (permalink / raw)
To: Andy Shevchenko, Jiri Kosina, Daniel J. Ogorchock, Petr Mladek,
Tamir Duberstein, linux-doc, linux-kernel, linux-input
Cc: Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky,
Jonathan Corbet, Shuah Khan, Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
Convert to %pM instead of using custom code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/hid/hid-nintendo.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 29008c2cc530..05c50f2530ef 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -2431,14 +2431,8 @@ static int joycon_read_info(struct joycon_ctlr *ctlr)
for (i = 4, j = 0; j < 6; i++, j++)
ctlr->mac_addr[j] = report->subcmd_reply.data[i];
- ctlr->mac_addr_str = devm_kasprintf(&ctlr->hdev->dev, GFP_KERNEL,
- "%02X:%02X:%02X:%02X:%02X:%02X",
- ctlr->mac_addr[0],
- ctlr->mac_addr[1],
- ctlr->mac_addr[2],
- ctlr->mac_addr[3],
- ctlr->mac_addr[4],
- ctlr->mac_addr[5]);
+ ctlr->mac_addr_str = devm_kasprintf(&ctlr->hdev->dev, GFP_KERNEL, "%pMU",
+ ctlr->mac_addr);
if (!ctlr->mac_addr_str)
return -ENOMEM;
hid_info(ctlr->hdev, "controller MAC = %s\n", ctlr->mac_addr_str);
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v15 02/12] lib: kstrtox: add local _parse_integer_limit_init() helper
From: Andy Shevchenko @ 2026-06-03 10:40 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky,
Shuah Khan
In-Reply-To: <r54csg73lsafo6rff7gew2eardfag3zmwjbm4jl54pjbqf6w7y@axnfog5wpney>
On Wed, Jun 03, 2026 at 11:27:11AM +0100, Rodrigo Alencar wrote:
> On 26/06/02 10:43PM, Andy Shevchenko wrote:
> > On Sun, May 31, 2026 at 09:30:45AM +0100, Rodrigo Alencar via B4 Relay wrote:
...
> > > +static unsigned int _parse_integer_limit_init(const char *s, unsigned int base,
> > > + unsigned long long init,
> >
> > Why not name it res...
>
> "res" is short for result and this is an init value. I suppose the compiler
> can optmize towards that kinda of efficiency. I thought of "p" itself to
> carry the init value, and the function would just accumulate, but that would
> change expectations on the function behavior.
> > > + unsigned long long *p,
> > > + size_t max_chars)
In any case I hope you saw my mini-series:
20260602203706.103449-1-andriy.shevchenko@linux.intel.com
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/18] perf test: Add workload-ctl option
From: Leo Yan @ 2026-06-03 10:40 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Arnaldo Carvalho de Melo,
Namhyung Kim, Jiri Olsa, Ian Rogers, Amir Ayupov, Jonathan Corbet,
Shuah Khan, Paschalis Mpeis, coresight, linux-perf-users,
linux-kernel, Arnaldo Carvalho de Melo, linux-doc
In-Reply-To: <20260602-james-cs-context-tracking-fix-v2-2-85b5ce6f55c6@linaro.org>
On Tue, Jun 02, 2026 at 03:26:44PM +0100, James Clark wrote:
[...]
> --- a/tools/perf/Documentation/perf-test.txt
> +++ b/tools/perf/Documentation/perf-test.txt
> @@ -69,3 +69,9 @@ OPTIONS
>
> --list-workloads::
> List the available workloads to use with -w/--workload.
> +
> +--workload-ctl=fifo:ctl-fifo[,ack-fifo]::
> + Write 'enable' to ctl-fifo before running the workload and 'disable'
> + before returning. If ack-fifo is provided, the workload runner waits for
> + an 'ack' response after each command. This scopes the recording to only
> + the workload if used with 'perf record -D 1 --control ...'.
This new option doesn't work on its own. I would spell out in explicit
words that it needs to communicate with perf record session:
"This option is used to communicate with a perf record session in
order to control the recording scope. When specifying this option,
the same FIFO path must be specified in the record session via:
perf record -D 1 --control=fifo:ctl-fifo[,ack-fifo] ...
The perf test sends 'enable' and 'disable' commands through ctl-fifo to
control event recording. If 'ack-fifo' is provided, the workload runner
waits for an 'ack' response after each command."
BTW, I'd say the naming "--record-ctl" might be more close to the
purpose.
Thanks,
Leo
^ 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