linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use __attribute__((malloc)) for gcc 3.2
Date: 29 Sep 2002 21:09:26 +0200	[thread overview]
Message-ID: <p733crssjdl.fsf@oldwotan.suse.de> (raw)
In-Reply-To: Christoph Hellwig's message of "29 Sep 2002 19:31:26 +0200"

Christoph Hellwig <hch@infradead.org> writes:

> On Sun, Sep 29, 2002 at 05:27:31PM +0200, Andi Kleen wrote:
> > -extern pgd_t *pgd_alloc(struct mm_struct *);
> > +extern pgd_t *pgd_alloc(struct mm_struct *) malloc_function;
> 
> Anz chance you could make that __malloc?  That how the other
> atrributes in the kernel (e.g. __init/__exit) work.

No.

> 
> > +/* Function allocates new memory and return cannot alias with anything */
> > +#define malloc_function __attribute__((malloc))
> > +/* Never inline */
> > +#define noinline __attribute__((noinline))
> > +#else
> > +#define malloc_function
> > +#define noinline
> > +#endif
> 
> Dito for __noinline?  And IMHO compiler.h is the better place for this.

Because I dislike all the __. It's just useless visual clutter and doesn't 
follow the usual convention of prefixing only low level functions with this.
Also now that the kernel has given up on ANSI/POSIX name space cleanliness
it is double plus useless.

Same thing for __get_cpu_var for example. The __ is completely useless.

I will move it into linux/compiler.h to add some more clutter to include hell,
because it requires even more #include <linux/compiler.h>

> BTW, do you have any stats on the better optimization?

With this it sings twice as loud and dances twice and a half times as fast.

No, with gcc 3.2 it doesn't seem to make much difference.

More important is that will allow better optimization by gcc in the future.
In kernel land the gcc optimizer is already a bit crippled because of 
the -fno-strict-aliasing use. This will hopefully help a bit.

-Andi

       reply	other threads:[~2002-09-29 19:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20020929152731.GA10631@averell.suse.lists.linux.kernel>
     [not found] ` <20020929182643.C8564@infradead.org.suse.lists.linux.kernel>
2002-09-29 19:09   ` Andi Kleen [this message]
2002-09-29 20:20     ` [PATCH] Use __attribute__((malloc)) for gcc 3.2 Adrian Bunk
2002-09-30  0:21     ` David S. Miller
2002-09-29 15:27 Andi Kleen
2002-09-29 16:24 ` Adrian Bunk
2002-09-29 17:26 ` Christoph Hellwig
2002-09-30  0:11   ` David S. Miller
2002-09-30  0:29     ` Andi Kleen
2002-09-29 20:01 ` Jakub Jelinek
2002-09-30  0:04   ` Andi Kleen
2002-10-07 10:05   ` Richard Henderson
2002-10-07 10:29     ` David S. Miller
2002-10-07 10:56       ` Andi Kleen
2002-10-07 11:07         ` Arjan van de Ven
2002-10-07 11:45         ` Richard Henderson
2002-10-07 12:27           ` Andi Kleen
2002-09-29 23:51 ` Anton Blanchard
2002-09-30  0:31   ` Andi Kleen
2002-09-30  1:07     ` Daniel Jacobowitz
2002-10-02 13:46     ` Pavel Machek

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=p733crssjdl.fsf@oldwotan.suse.de \
    --to=ak@suse.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@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 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).