From: Dave Chinner <david@fromorbit.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: allow disabling xfs tracepoints via Kconfig
Date: Tue, 5 Feb 2019 10:13:46 +1100 [thread overview]
Message-ID: <20190204231346.GC14116@dastard> (raw)
In-Reply-To: <4d66f2c2-bf5c-be47-9ef1-e581c5901823@rasmusvillemoes.dk>
On Mon, Feb 04, 2019 at 11:12:57PM +0100, Rasmus Villemoes wrote:
> On 04/02/2019 22.53, Dave Chinner wrote:
> > On Mon, Feb 04, 2019 at 10:20:35PM +0100, Rasmus Villemoes wrote:
> >> linux/tracepoints.h allows individual subsystems to disable their
> >> tracepoints. Add such a knob for xfs. Disabling XFS_TRACEPOINTS
> >> reduces the resident size of xfs.ko by about a third, or ~350 KiB.
> >
> > Ok, now we can't debug typical problems on live production systems
> > if tracepoints are turned off on the user/distro kernels. So under
> > what circumstances would we ever want to turn off tracepoints on
> > XFS?
>
> I don't expect any mainstream distros to turn it off. But for embedded
> systems that use a hand-tuned .config, being able to shave off 100s of K
> of the kernel image is quite valuable.
However, small embedded systems don't use XFS because of it's size,
dependence on 64 bit capability (ie. 64BIT || LBDAF), its CPU and
memory overhead in comparison to other filesystems, etc.
Increasing kconfig options increases the test matrix (even just the
"does this changeset compile" matrix) so these things don't come for
free. XFS is firmly focussed on the other end of the scale (big,
lots, fast), so I'm not sure that increasing the kconfig combination
matrix to cater for really low end embedded systems is really that
worthwhile.
> Tracing _is_ useful,
> also/especially when doing embedded development, which is why "just turn
> off CONFIG_TRACING" isn't really an option.
Do you have a specific need for this, or is it just "I noticed this,
here's a patch"? If you need it and will use it, great, let's add
it. But config options that don't ever get used tend to rot....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-02-04 23:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 21:20 [PATCH] xfs: allow disabling xfs tracepoints via Kconfig Rasmus Villemoes
2019-02-04 21:37 ` Darrick J. Wong
2019-02-04 21:53 ` Dave Chinner
2019-02-04 22:12 ` Rasmus Villemoes
2019-02-04 23:13 ` Dave Chinner [this message]
2019-02-05 10:00 ` Rasmus Villemoes
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=20190204231346.GC14116@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
/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