public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Hugh Dickins <hugh@veritas.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] BUG preserve registers
Date: Sat, 09 Feb 2002 20:20:51 -0800	[thread overview]
Message-ID: <3C65F523.FDDB7FA@zip.com.au> (raw)
In-Reply-To: <3C659D8A.37EA0155@zip.com.au> from "Andrew Morton" at Feb 09, 2002 02:07:06 PM <E16Zjw9-0000Dr-00@the-village.bc.nu>

Alan Cox wrote:
> 
> > This works for me, from in-kernel as well as in-module.  It'd
> > be good if someone more familiar with x86 could check it over.
> 
> This looks a really bad reversion. The CONFIG_DEBUG_BUGVERBOSE ifdef saves
> over 70K of memory on my standard kernel build.

About the time the 70k claim was made, I moved the printk out-of-line,
so things got not so bad.  However, with my (large) kernel build, on
egcs-1.1.2:

non-verbose BUG:
        2589971  293436  373404 3256811  31b1eb vmlinux
verbose BUG:
        2709055  293436  373404 3375895  338317 vmlinux
Patched:
        2694537  293436  373404 3361377  334a61 vmlinux

Which is 100k, which is preposterous.

This is due to BUG() calls in inline functions in headers.  The biggest
culprit is dget(), in dcache.h.  This causes the full path of the header file
to be expanded into each and every compilation unit which includes
dcache.h.  In my build, it's 25 kilobytes of:

...
/net/akpm-1/usr/src/linux-akpm/include/linux/dcache.h
/net/akpm-1/usr/src/linux-akpm/include/linux/dcache.h                           /net/akpm-1/usr/src/linux-akpm/include/linux/dcache.h
...

I'm showing thirteen header files, for a total of 83k.  I'll do something
about this...

> Putting the file name pointers
> back in everywhere is going to put a fair amount of that back except on
> very new gcc's that maybe will do string merging in this case. Have you
> verified string merging occurs in gcc 2.95 for __FILE__ string constants
> passed into asm blocks ?

Yes, the compiler gets it right.
 
> I also don't understand what the problem you are trying to solve is. If you
> want to debug the kernel you build with debug verbose. If not you don't.
> With the symbol table you can still easily trace down BUG events.
> 

Alan, the thing I really don't like about the config option is
when people come onto this list reporting that they got a "Kernel
BUG" and we simply don't know where it happened.  It's especially
hard when we have a bunch of BUGs near together, such as the
rather popular ones in page_alloc.c

Fixing the above problem should reduce the overhead from 100k down
to 20k.  I'll also change the implementation to

#if 1   /* Set to zero for a slightly smaller kernel */
#define BUG()                           \
 __asm__ __volatile__(  "ud2\n"         \
                        "\t.word %c0\n" \
                        "\t.long %c1\n" \
                         : : "i" (__LINE__), "i" (__FILE__))
#else
#define BUG() __asm__ __volatile__("ud2\n")
#endif

And we can add this to the list of kernel unpiggying tricks
which Lars Brinkhoff developed, which I guess should really
be in the Documentation/ directory somewhere.

But I dislike the config option, because of the information
loss to us.

-

  reply	other threads:[~2002-02-10  4:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-09  8:13 [PATCH] BUG preserve registers Hugh Dickins
2002-02-09  8:32 ` Andrew Morton
2002-02-09 10:33   ` Hugh Dickins
2002-02-09 19:30 ` Linus Torvalds
2002-02-09 19:34   ` Andrew Morton
2002-02-09 21:37     ` Linus Torvalds
2002-02-09 20:00       ` H. Peter Anvin
2002-02-09 21:49         ` Linus Torvalds
2002-02-09 20:24           ` H. Peter Anvin
2002-02-09 20:11       ` Andrew Morton
2002-02-09 20:15         ` Linus Torvalds
2002-02-09 22:07           ` Andrew Morton
2002-02-10  2:41             ` Alan Cox
2002-02-10  4:20               ` Andrew Morton [this message]
2002-02-10  4:23                 ` H. Peter Anvin
2002-02-10  4:28                   ` Andrew Morton
2002-02-10  6:16                 ` Linus Torvalds
2002-02-10  5:28                   ` Andrew Morton
2002-02-10  7:23                     ` Linus Torvalds
2002-02-10  6:28                       ` Andrew Morton
2002-02-10  9:05                         ` Andrew Morton
     [not found]                           ` <200202110710.g1B7A5t28328@Port.imtp.ilyichevsk.odessa.ua>
2002-02-11  7:22                             ` Andrew Morton
2002-02-11 17:19                           ` Hugh Dickins
2002-02-11 19:48                             ` Andrew Morton
2002-02-11 20:52                               ` Hugh Dickins
2002-02-10  7:13                       ` H. Peter Anvin
2002-02-10  8:53                         ` arjan
2002-02-11 15:26                     ` Jamie Lokier
2002-02-10  6:23                   ` Eric W. Biederman
2002-02-10  6:50                     ` Andrew Morton
2002-02-10 15:40                       ` Eric W. Biederman
2002-02-10  7:08                     ` Stevie O
2002-02-10 14:35                   ` Olaf Dietsche
2002-02-10  4:55               ` Linus Torvalds
2002-02-10  5:03               ` Linus Torvalds
2002-02-10  4:21       ` Brian Gerst

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=3C65F523.FDDB7FA@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hpa@zytor.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=torvalds@transmeta.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