From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
xfs <linux-xfs@vger.kernel.org>
Subject: Re: [RFC PATCH] xfs: consolidate local format inode fork verifiers
Date: Mon, 24 Jul 2017 14:36:51 -0400 [thread overview]
Message-ID: <20170724183651.GA12942@bfoster.bfoster> (raw)
In-Reply-To: <20170724130752.GA11537@bfoster.bfoster>
On Mon, Jul 24, 2017 at 09:07:52AM -0400, Brian Foster wrote:
> On Mon, Jul 24, 2017 at 03:26:38PM +1000, Dave Chinner wrote:
> > On Sat, Jul 22, 2017 at 08:29:44AM -0400, Brian Foster wrote:
> > > On Sat, Jul 22, 2017 at 09:00:58AM +1000, Dave Chinner wrote:
> > > > On Fri, Jul 21, 2017 at 09:54:05AM -0400, Brian Foster wrote:
> > > > > On Fri, Jul 21, 2017 at 08:49:34AM +1000, Dave Chinner wrote:
...
>
> [1] A simple test that we can do at the moment is to compare a
> production xfs.ko with one with asserts enabled. My local for-next
> branch builds a module of 40104000 bytes without XFS_WARN and 40540208
> bytes with XFS_WARN enabled. That makes for a difference of ~425k and
> roughly a 1% code size increase (accounting for ~1750 asserts and
> supporting code).
>
FWIW, the huge size here didn't register to me until Darrick mentioned
it on irc. I'm guessing I have a bunch of debug enabled in my kernel
config (that I don't really want to disable right now). If I strip the
resulting module binaries, I end up with 1076736 bytes vs. 1210624 bytes
(for a 130kb delta and ~12% increase), which I'm guessing is a more
accurate assessment.
Brian
> [2] We may not want to use ASSERT() here, but perhaps define a new
> variant to omit the stack trace and otherwise customize to a verifier
> report.
>
> > Cheers,
> >
> > Dave.
> >
> > --
> > Dave Chinner
> > david@fromorbit.com
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-07-24 18:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-19 16:03 [RFC PATCH] xfs: consolidate local format inode fork verifiers Darrick J. Wong
2017-07-20 2:26 ` Dave Chinner
2017-07-20 5:50 ` Darrick J. Wong
2017-07-20 22:49 ` Dave Chinner
2017-07-21 13:54 ` Brian Foster
2017-07-21 23:00 ` Dave Chinner
2017-07-22 12:29 ` Brian Foster
2017-07-24 5:26 ` Dave Chinner
2017-07-24 13:07 ` Brian Foster
2017-07-24 18:36 ` Brian Foster [this message]
2017-07-24 18:44 ` Darrick J. Wong
2017-07-24 19:34 ` Brian Foster
2017-07-24 17:15 ` Darrick J. Wong
2017-07-20 11:51 ` Brian Foster
2017-07-20 20:20 ` Darrick J. Wong
2017-07-21 12:58 ` Brian Foster
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=20170724183651.GA12942@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.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.