From: David Hildenbrand <david@redhat.com>
To: Alex Markuze <amarkuze@redhat.com>,
ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org,
bsegall@google.com, dietmar.eggemann@arm.com, idryomov@gmail.com,
mingo@redhat.com, juri.lelli@redhat.com, kees@kernel.org,
lorenzo.stoakes@oracle.com, mgorman@suse.de, mhocko@suse.com,
rppt@kernel.org, peterz@infradead.org, rostedt@goodmis.org,
surenb@google.com, vschneid@redhat.com,
vincent.guittot@linaro.org, vbabka@suse.cz, xiubli@redhat.com,
Slava.Dubeyko@ibm.com
Subject: Re: [RFC PATCH 0/5] BLOG: per-task logging contexts with Ceph consumer
Date: Fri, 24 Oct 2025 17:32:52 +0200 [thread overview]
Message-ID: <94d62ba4-e203-408e-9200-b153ce97555d@redhat.com> (raw)
In-Reply-To: <20251024084259.2359693-1-amarkuze@redhat.com>
On 24.10.25 10:42, Alex Markuze wrote:
> Motivation: improve observability in production by providing subsystemsawith
> a logger that keeps up with their verbouse unstructured logs and aggregating
> logs at the process context level, akin to userspace TLS.
>
> Binary LOGging (BLOG) introduces a task-local logging context: each context
> owns a single 512 KiB fragment that cycles through “ready → in use → queued for
> readers → reset → ready” without re-entering the allocator. Writers copy the
> raw parameters they already have; readers format them later when the log is
> inspected.
>
> BLOG borrows ideas from ftrace (captureabinary data now, format later) but
> unlike ftrace there is no global ring. Each module registers its own logger,
> manages its own buffers, and keeps the state small enough for production use.
>
> To host the per-module pointers we extend `struct task_struct` with one
> additional `void *`, in line with other task extensions already in the kernel.
> Each module keeps independent batches: `alloc_batch` for contexts with
> refcount 0 and `log_batch` for contexts that have been filled and are waiting
> for readers. The batching layer and buffer management were migrated from the
> existing Ceph SAN logging code, so the behaviour is battle-tested; we simply
> made the buffer inline so every composite stays within a single 512 KiB
> allocation.
>
> The patch series lands the BLOG library first, then wires the task lifecycle,
> and finally switches Ceph’s `bout*` logging macros to BLOG so we exercise the
> new path.
>
> Patch summary:
> 1. sched, fork: wire BLOG contexts into task lifecycle
> - Adds `struct blog_tls_ctx *blog_contexts[BLOG_MAX_MODULES]` to
> `struct task_struct`.
> - Fork/exit paths initialise and recycle contexts automatically.
>
> 2. lib: introduce BLOG (Binary LOGging) subsystem
> - Adds `lib/blog/` sources and headers under `include/linux/blog/`.
> - Each composite (`struct blog_tls_pagefrag`) consists of the TLS
> metadata, the pagefrag state, and an inline buffer sized at
> `BLOG_PAGEFRAG_SIZE - sizeof(struct blog_tls_pagefrag)`.
>
> 3. ceph: add BLOG scaffolding
> - Introduces `include/linux/ceph/ceph_blog.h` and `fs/ceph/blog_client.c`.
> - Ceph registers a logger and maintains a client-ID map for the reader
> callback.
>
> 4. ceph: add BLOG debugfs support
> - Adds `fs/ceph/blog_debugfs.c` so filled contexts can be drained.
>
> 5. ceph: activate BLOG logging
> - Switches `bout*` macros to BLOG, making Ceph the first consumer.
Hi!
You CCed plenty of MM folks, and I am sure most of them observe "this
doesn't seem to touch any core-mm files" and wonder "what's hiding in
there that requires a pair of MM eyes".
Is there anything specific we should be looking at (and if so, in which
patch)?
--
Cheers
David / dhildenb
next prev parent reply other threads:[~2025-10-24 15:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 8:42 [RFC PATCH 0/5] BLOG: per-task logging contexts with Ceph consumer Alex Markuze
2025-10-24 8:42 ` [RFC PATCH 1/5] sched, fork: Wire BLOG contexts into task lifecycle Alex Markuze
2025-10-24 17:44 ` Steven Rostedt
2025-10-29 18:57 ` Viacheslav Dubeyko
2025-10-24 8:42 ` [RFC PATCH 2/5] lib: Introduce BLOG (Binary LOGging) subsystem Alex Markuze
2025-10-30 18:47 ` Viacheslav Dubeyko
2025-10-24 8:42 ` [RFC PATCH 3/5] ceph: Add BLOG scaffolding Alex Markuze
2025-11-03 22:37 ` Viacheslav Dubeyko
2025-10-24 8:42 ` [RFC PATCH 4/5] ceph: Add BLOG debugfs support Alex Markuze
2025-11-03 21:07 ` Viacheslav Dubeyko
2025-10-24 8:42 ` [RFC PATCH 5/5] ceph: Activate BLOG logging Alex Markuze
2025-11-03 21:00 ` Viacheslav Dubeyko
2025-10-24 15:32 ` David Hildenbrand [this message]
2025-10-24 17:53 ` [RFC PATCH 0/5] BLOG: per-task logging contexts with Ceph consumer Steven Rostedt
2025-10-25 10:50 ` Alex Markuze
2025-10-25 14:59 ` Steven Rostedt
2025-10-25 17:54 ` Alex Markuze
2025-10-27 14:54 ` Steven Rostedt
2025-10-28 17:07 ` Viacheslav Dubeyko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94d62ba4-e203-408e-9200-b153ce97555d@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=Slava.Dubeyko@ibm.com \
--cc=akpm@linux-foundation.org \
--cc=amarkuze@redhat.com \
--cc=bsegall@google.com \
--cc=ceph-devel@vger.kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=idryomov@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xiubli@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).