From: Jesper Juhl <jesper.juhl@gmail.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Con Kolivas <kernel@kolivas.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] inline a few tiny functions in init/initramfs.c
Date: Wed, 28 Sep 2005 02:07:48 +0200 [thread overview]
Message-ID: <9a87484905092717074e85657e@mail.gmail.com> (raw)
In-Reply-To: <4334DB96.3040904@yahoo.com.au>
On 9/24/05, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Con Kolivas wrote:
>
> >On Sat, 24 Sep 2005 09:26, Jesper Juhl wrote:
> >
> >>A few functions in init/initramfs.c are so simple that I don't see why
> >>*any* point in them having to bear the cost of a function call.
> >>Wouldn't something like the patch below make sense ?
> >>
> >
> >>-static void __init *malloc(size_t size)
> >>+static inline void __init *malloc(size_t size)
> >> {
> >> return kmalloc(size, GFP_KERNEL);
> >>
> >
> >maybe it looks like it would, but kmalloc looks like this:
> >
> >85 static inline void *kmalloc(size_t size, int flags)
> >86 {
> >87 if (__builtin_constant_p(size)) {
> >88 int i = 0;
> >89 #define CACHE(x) \
> >90 if (size <= x) \
> >91 goto found; \
> >92 else \
> >93 i++;
> >94 #include "kmalloc_sizes.h"
> >95 #undef CACHE
> >96 {
> >97 extern void __you_cannot_kmalloc_that_much(void);
> >98 __you_cannot_kmalloc_that_much();
> >99 }
> >100 found:
> >101 return kmem_cache_alloc((flags & GFP_DMA) ?
> >102 malloc_sizes[i].cs_dmacachep :
> >103 malloc_sizes[i].cs_cachep, flags);
> >104 }
> >105 return __kmalloc(size, flags);
> >106 }
> >
> >which is not a one liner to inline at all
> >
> >
>
> Actually, this is even better, because the inline 'malloc' should be
> able to propogate the builtin_constantness of 'size' while an out of
> line version cannot.
>
> IMO the best policy is not to second guess the API implementor's
> choice of inline / noinline. That is - if kmalloc was too big to
> inline then it should be fixed in kmalloc or another interface
> introduced.
>
Ok, so it seems that there's agreement that the other two inlines in
the patch makes sense, but the malloc() is not clear cut.
Since this is in initramfs after all it doesn't make that big a
difference overall, so I'll just send in a patch that inlines the
other two functions but leaves malloc() alone.
Thank you both, Nick, Con, for commenting.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
next prev parent reply other threads:[~2005-09-28 0:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-23 23:26 [RFC][PATCH] inline a few tiny functions in init/initramfs.c Jesper Juhl
2005-09-24 4:15 ` Con Kolivas
2005-09-24 4:52 ` Nick Piggin
2005-09-28 0:07 ` Jesper Juhl [this message]
2005-09-28 1:56 ` Nick Piggin
2005-09-28 3:01 ` Coywolf Qi Hunt
2005-09-28 21:38 ` Jesper Juhl
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=9a87484905092717074e85657e@mail.gmail.com \
--to=jesper.juhl@gmail.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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