LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Denys Vlasenko <vda.linux@googlemail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 7/8] Immediate Values - Documentation
Date: Fri, 21 Sep 2007 16:51:51 +0100	[thread overview]
Message-ID: <200709211651.51851.vda.linux@googlemail.com> (raw)
In-Reply-To: <20070921133103.GA14844@Krystal>

On Friday 21 September 2007 14:31, Mathieu Desnoyers wrote:
> > Immediates make code bigger, right?
> 
> Nope.
> 
> Example:
> 
> char x;
> 
> void testb(void)
> {
>         if (x > 5)
>                 testa();
> }
> 
> Would turn into:
>   56:   b0 00                   mov    $0x0,%al
>   58:   3c 05                   cmp    $0x5,%al
>   5a:   7e 05                   jle    61 <testb+0x11>
> 
> (6 bytes)
> 
> Rather than:
> 
>   56:   80 3d 00 00 00 00 05    cmpb   $0x5,0x0
>   5d:   7e 05                   jle    64 <testb+0x14>
> 
> (9 bytes)

For 32-bit value, you won't be so lucky.

> So actually, immediate values well used make the code smaller. By the
> way, I recommend using the smallest immediate values required, which
> will often be a single byte.

I agree on this wholeheartedy. However, current kernel mostly uses int
even for yes/no style flags.

> > getppid is one of the lightest syscalls out there.
> > What kind of speedup do you see on a real-world test
> > (two processes exchaging data through pipes, for example)?
> > 
> 
> With the size of the caches we currently have, that kind of workload
> will not show any measurable difference: the signal/noise ratio is way
> to small to detect that kind of performance difference under such
> workload. Try it if you want.

Exactly my point: this speedup is not measurable on realistic workload.

> The real-world speedup I am interested into is to have almost -zero-
> tracer impact, which imples being undetectable even in the smallest and
> shortest functions. I guess nobody is interested in adding a measurable
> performance hit to kmalloc fast path, right?
> 
> > > +Therefore, not only is it interesting to use the immediate values to dynamically
> > > +activate dormant code such as the markers, but I think it should also be
> > > +considered as a replacement for many of the "read mostly" static variables.
> > 
> > What effect that will have on "size vmlinux" on AMD64?
> 
> Without considering kernel/immediate.o, it will make the code smaller
> and add 3*8bytes=24bytes of data in the __immediate section per
> immediate value reference (data only used for updates).

Yes. *Per immediate value reference*.

Therefore I don't think it's wise to recommend to use __immediate
for any variables which are referenced many times. "Many" defined as
"more than ten".

IOW: I think that this last paragraph shouldn't be there:

On Tuesday 18 September 2007 22:07, Mathieu Desnoyers wrote:
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> ---
>  Documentation/immediate.txt |  228 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 228 insertions(+)
>...
> +Therefore, not only is it interesting to use the immediate values to dynamically
> +activate dormant code such as the markers, but I think it should also be
> +considered as a replacement for many of the "read-mostly" static variables.


A few crazy ideas how you can make it slightly less painful for 64-bit arch:

* Pack last long ('size') into low bits of other fields.
  (I expect link stage problems, tho)


* Make last field uint8_t and pack whole struct into 17 bytes (__attribute__((packed)))
  instead of 24 bytes.
  Expect align-happy folks faint left and right at such horrendous crime :) but
  other than that, it will work. Updates of immediates will *maybe* get a tiny bit slower
  (which is unimportant anyway).

  [btw, this can be done for i386 too]


* Turn long's into int32_t, since kernel's text addresses (at least on AMD64)
  fit into int32_t (sign-extend will give you correct 64-bit address):

  ffffffff80200000 A _text
  ffffffff80200000 T startup_64
  ffffffff802000b7 t ident_complete
  ffffffff80200110 T secondary_startup_64
  ffffffff802001a8 T initial_code
  ffffffff802001b0 T init_rsp
  ffffffff802001b8 t bad_address
  ffffffff802001c0 T early_idt_handler

  [I hope there is suitable reloc type for AMD64 and ld won't complain]
--
vda

  reply	other threads:[~2007-09-21 15:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-27 15:59 [patch 0/8] Immediate Values Mathieu Desnoyers
2007-08-27 15:59 ` [patch 1/8] Immediate Values - Global Modules List and Module Mutex Mathieu Desnoyers
2007-08-27 15:59 ` [patch 2/8] Immediate Values - Architecture Independent Code Mathieu Desnoyers
2007-08-27 15:59 ` [patch 3/8] Immediate Values - Kconfig menu in EMBEDDED Mathieu Desnoyers
2007-08-27 15:59 ` [patch 4/8] Immediate Values - Move Kprobes i386 restore_interrupt to kdebug.h Mathieu Desnoyers
2007-08-27 15:59 ` [patch 5/8] Immediate Values - i386 Optimization Mathieu Desnoyers
2007-08-27 15:59 ` [patch 6/8] Immediate Values - Powerpc Optimization Mathieu Desnoyers
2007-08-27 15:59 ` [patch 7/8] Immediate Values - Documentation Mathieu Desnoyers
2007-09-20 10:46   ` Denys Vlasenko
2007-09-21 13:31     ` Mathieu Desnoyers
2007-09-21 15:51       ` Denys Vlasenko [this message]
2007-08-27 15:59 ` [patch 8/8] Scheduler Profiling - Use Immediate Values Mathieu Desnoyers
  -- strict thread matches above, loose matches on Subject: below --
2007-11-13 18:58 [patch 0/8] Immediate Values (now with merged x86 support) Mathieu Desnoyers
2007-11-13 18:58 ` [patch 7/8] Immediate Values - Documentation Mathieu Desnoyers
2007-08-20 20:23 [patch 0/8] Immediate Values Mathieu Desnoyers
2007-08-20 20:24 ` [patch 7/8] Immediate Values - Documentation Mathieu Desnoyers
2007-08-12 15:07 [patch 0/8] Immediate Values Mathieu Desnoyers
2007-08-12 15:07 ` [patch 7/8] Immediate Values - Documentation Mathieu Desnoyers

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=200709211651.51851.vda.linux@googlemail.com \
    --to=vda.linux@googlemail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --subject='Re: [patch 7/8] Immediate Values - Documentation' \
    /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

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).