Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output

[PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Davidlohr Bueso <dave@stgolabs.net> · 2023-05-01
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-01
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Andy Shevchenko <hidden> · 2023-05-01
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Liam R. Howlett <hidden> · 2023-05-01
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-01
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · James Bottomley <James.Bottomley@HansenPartnership.com> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Andy Shevchenko <hidden> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Andy Shevchenko <hidden> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Andy Shevchenko <hidden> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Andy Shevchenko <hidden> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · James Bottomley <James.Bottomley@HansenPartnership.com> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Dave Chinner <david@fromorbit.com> · 2023-05-02
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Vlastimil Babka <hidden> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Andy Shevchenko <hidden> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · James Bottomley <James.Bottomley@HansenPartnership.com> · 2023-05-03
Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output · Jani Nikula <jani.nikula@linux.intel.com> · 2023-05-02
[PATCH 02/40] scripts/kallysms: Always include __start and __stop symbols · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 03/40] fs: Convert alloc_inode_sb() to a macro · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 03/40] fs: Convert alloc_inode_sb() to a macro · Petr Tesařík <hidden> · 2023-05-02
Re: [PATCH 03/40] fs: Convert alloc_inode_sb() to a macro · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-02
Re: [PATCH 03/40] fs: Convert alloc_inode_sb() to a macro · Petr Tesařík <hidden> · 2023-05-02
[PATCH 04/40] nodemask: Split out include/linux/nodemask_types.h · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 05/40] prandom: Remove unused include · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 06/40] lib/string.c: strsep_no_empty() · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 06/40] lib/string.c: strsep_no_empty() · Petr Tesařík <hidden> · 2023-05-02
[PATCH 07/40] Lazy percpu counters · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 07/40] Lazy percpu counters · Randy Dunlap <hidden> · 2023-05-01
[PATCH 08/40] mm: introduce slabobj_ext to support slab object extensions · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 09/40] mm: introduce __GFP_NO_OBJ_EXT flag to selectively prevent slabobj_ext creation · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 09/40] mm: introduce __GFP_NO_OBJ_EXT flag to selectively prevent slabobj_ext creation · Petr Tesařík <hidden> · 2023-05-02
Re: [PATCH 09/40] mm: introduce __GFP_NO_OBJ_EXT flag to selectively prevent slabobj_ext creation · Suren Baghdasaryan <surenb@google.com> · 2023-05-02
[PATCH 10/40] mm/slab: introduce SLAB_NO_OBJ_EXT to avoid obj_ext creation · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 11/40] mm: prevent slabobj_ext allocations for slabobj_ext and kmem_cache objects · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 12/40] slab: objext: introduce objext_flags as extension to page_memcg_data_flags · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 13/40] lib: code tagging framework · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 14/40] lib: code tagging module support · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 15/40] lib: prevent module unloading if memory is not freed · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 16/40] lib: code tagging query helper functions · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 17/40] lib: add allocation tagging support for memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 25/40] mm/slab: enable slab allocation tagging for kmalloc and friends · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 18/40] lib: introduce support for page allocation tagging · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Petr Tesařík <hidden> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Suren Baghdasaryan <surenb@google.com> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Petr Tesařík <hidden> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Suren Baghdasaryan <surenb@google.com> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Petr Tesařík <hidden> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Suren Baghdasaryan <surenb@google.com> · 2023-05-02
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Steven Rostedt <rostedt@goodmis.org> · 2023-05-03
Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
[PATCH 20/40] mm: enable page allocation tagging · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 21/40] mm/page_ext: enable early_page_ext when CONFIG_MEM_ALLOC_PROFILING_DEBUG=y · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 22/40] mm: create new codetag references during page splitting · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 23/40] lib: add codetag reference into slabobj_ext · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 30/40] mm: percpu: Add codetag reference into pcpuobj_ext · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 24/40] mm/slab: add allocation accounting into slab allocation and free paths · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 26/40] mm/slub: Mark slab_free_freelist_hook() __always_inline · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 27/40] mempool: Hook up to memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 28/40] timekeeping: Fix a circular include dependency · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 28/40] timekeeping: Fix a circular include dependency · Thomas Gleixner <hidden> · 2023-05-02
[PATCH 37/40] codetag: debug: skip objext checking when it's for objext itself · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 29/40] mm: percpu: Introduce pcpuobj_ext · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 31/40] mm: percpu: enable per-cpu allocation tagging · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 32/40] arm64: Fix circular header dependency · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 33/40] move stack capture functionality into a separate function for reuse · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 34/40] lib: code tagging context capture support · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 34/40] lib: code tagging context capture support · Michal Hocko <mhocko@suse.com> · 2023-05-03
Re: [PATCH 34/40] lib: code tagging context capture support · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 34/40] lib: code tagging context capture support · Dave Hansen <hidden> · 2023-05-03
Re: [PATCH 34/40] lib: code tagging context capture support · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 34/40] lib: code tagging context capture support · Michal Hocko <mhocko@suse.com> · 2023-05-04
Re: [PATCH 34/40] lib: code tagging context capture support · Suren Baghdasaryan <surenb@google.com> · 2023-05-04
[PATCH 35/40] lib: implement context capture support for tagged allocations · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 35/40] lib: implement context capture support for tagged allocations · Michal Hocko <mhocko@suse.com> · 2023-05-03
Re: [PATCH 35/40] lib: implement context capture support for tagged allocations · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 35/40] lib: implement context capture support for tagged allocations · Michal Hocko <mhocko@suse.com> · 2023-05-04
Re: [PATCH 35/40] lib: implement context capture support for tagged allocations · Suren Baghdasaryan <surenb@google.com> · 2023-05-04
Re: [PATCH 35/40] lib: implement context capture support for tagged allocations · Michal Hocko <mhocko@suse.com> · 2023-05-05
Re: [PATCH 35/40] lib: implement context capture support for tagged allocations · Suren Baghdasaryan <surenb@google.com> · 2023-05-05
[PATCH 36/40] lib: add memory allocations report in show_mem() · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 38/40] codetag: debug: mark codetags for reserved pages as empty · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 39/40] codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
[PATCH 40/40] MAINTAINERS: Add entries for code tagging and memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 00/40] Memory allocation profiling · Roman Gushchin <roman.gushchin@linux.dev> · 2023-05-01
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-01
Re: [PATCH 00/40] Memory allocation profiling · Roman Gushchin <roman.gushchin@linux.dev> · 2023-05-01
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-01
Re: [PATCH 00/40] Memory allocation profiling · Roman Gushchin <roman.gushchin@linux.dev> · 2023-05-01
Re: [PATCH 00/40] Memory allocation profiling · Michal Hocko <mhocko@suse.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Michal Hocko <mhocko@suse.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Steven Rostedt <rostedt@goodmis.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Johannes Weiner <hannes@cmpxchg.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Johannes Weiner <hannes@cmpxchg.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Tejun Heo <tj@kernel.org> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Andrey Ryabinin <ryabinin.a.a@gmail.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · James Bottomley <James.Bottomley@HansenPartnership.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Lorenzo Stoakes <hidden> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · James Bottomley <James.Bottomley@HansenPartnership.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Steven Rostedt <rostedt@goodmis.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Steven Rostedt <rostedt@goodmis.org> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-03
Re: [PATCH 00/40] Memory allocation profiling · Michal Hocko <mhocko@suse.com> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Suren Baghdasaryan <surenb@google.com> · 2023-05-04
Re: [PATCH 00/40] Memory allocation profiling · Michal Hocko <mhocko@suse.com> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Steven Rostedt <rostedt@goodmis.org> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Steven Rostedt <rostedt@goodmis.org> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-07
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-08
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-08
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-08
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-08
Re: [PATCH 00/40] Memory allocation profiling · Petr Tesařík <hidden> · 2023-05-08
Re: [PATCH 00/40] Memory allocation profiling · Kent Overstreet <kent.overstreet@linux.dev> · 2023-05-08

From: Kent Overstreet <kent.overstreet@linux.dev>
Date: 2023-05-03 09:16:48
Also in: cgroups, linux-arch, linux-doc, linux-fsdevel, linux-iommu, linux-mm, lkml

On Wed, May 03, 2023 at 12:12:12PM +0300, Andy Shevchenko wrote:

quoted

So, are you dropping your NACK then, so we can standardize the kernel on
the way everything else does it?

No, you are breaking existing users. The NAK stays.
The whole discussion after that is to make the way on how users can
utilize your format and existing format without multiplying APIs.

Dave seems to think we shouldn't be, and I'm in agreement.

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help