From: David Laight <David.Laight@ACULAB.COM>
To: 'Steven Rostedt' <rostedt@goodmis.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: RE: [for-linus][PATCH 0/3] tracing: Fixes for v6.8
Date: Sun, 10 Mar 2024 18:16:06 +0000 [thread overview]
Message-ID: <550b6c44aa434b5b91e999a8d073527c@AcuMS.aculab.com> (raw)
In-Reply-To: <20240306184244.754263547@goodmis.org>
...
> Another issue that was brought up is that the trace_seq buffer is
> also based on PAGE_SIZE even though it is not tied to the architecture
> limit like the ring buffer sub-buffer is. Having it be 64K * 2 is
> simply just too big and wasting memory on systems with 64K page sizes.
> It is now hardcoded to 8K which is what all other architectures with
> 4K PAGE_SIZE has.
Does Linux use a 2k PAGE_SIZE on any architectures?
IIRC m68k hardware has a 2k page, but Linux might always pair them.
A 2k page might (or might not) cause grief.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2024-03-10 18:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 18:42 [for-linus][PATCH 0/3] tracing: Fixes for v6.8 Steven Rostedt
2024-03-06 18:42 ` [for-linus][PATCH 1/3] tracing: Remove precision vsnprintf() check from print event Steven Rostedt
2024-03-06 18:42 ` [for-linus][PATCH 2/3] tracing: Limit trace_seq size to just 8K and not depend on architecture PAGE_SIZE Steven Rostedt
2024-03-06 18:42 ` [for-linus][PATCH 3/3] tracing: Limit trace_marker writes to just 4K Steven Rostedt
2024-03-10 18:16 ` David Laight [this message]
2024-03-10 18:36 ` [for-linus][PATCH 0/3] tracing: Fixes for v6.8 Steven Rostedt
2024-03-10 19:12 ` Geert Uytterhoeven
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=550b6c44aa434b5b91e999a8d073527c@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.