Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Nikolaos Korkakakis <nikolaos.korkakakis@sitelsemi.com>
To: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org, korkakak@gmail.com
Subject: Shadow registers optimizations
Date: Mon, 28 Feb 2011 10:15:04 +0200	[thread overview]
Message-ID: <4D6B5988.70406@sitelsemi.com> (raw)

Good morning list,

I would like to do some optimizations in the kernel to boost even more 
the performance of the m14kc (and potentially m4 series as well). One of 
the interesting ideas that has the potential in a busy system to provide 
higher performance are the shadow registers for interrupt handling code 
(maybe there are other usages for shadow registers in other areas by I 
leave this aside).

I had a somewhat long talk with Ralf over irc last friday, which started 
from the point that in kernel/traps.c there are two vi handler 
installers. A helper (set_vi_srs_handler) and a wrapper of the helper 
(set_vi_handler)

the helper in case of shadow sets exists it only adds a jump in the vi 
table (the "0x08000000 | (((u32)handler >> 2) & 0x03fffff);" is that 
kind of magic) followed by a nop. that's all. that's ok for a helper but 
it may have a performance impact since on each dump the whole execution 
pipeline is flushed, not to mention the actual loss of the whole 
VECTORSPACING (which is hard set to 0x100 bytes) memory space for just 
8bytes of code.

So I intend to change some things around the traps code.
  - The first is how the VECTORSPACING is defined (no constant 
declaration anymore) it is gonna be a dynamic init based setup that 
would alter the intctl register as it ought to in the first place
  - the second is that in case of shadow register != 0 the handlers (ie 
the plat_irq_dispatch) should be copied there if the VECTORSPACING space 
is sufficient or else use the jump install code

loose ends. Ralf mentioned that the usage of shadow registers is not 
str8 fwd and a careful approach should be taken. those are
  1) arch/mips/kernel/entry.S  _TIF_NEED_RESCHED
  2) asm/irq_regs.h get_irq_regs() [rdpgpr and wrpgpr]
  3) <add yours>

For 1 and 2 the solution seems pretty trivial, but if you have any other 
ideas please elaborate on this so the loose ends are pinpointed and 
attacked.

BR,
N

-- 
Nikolaos Korkakakis
Embedded Software Engineer
Tel:         +30 2610 390 948
OS and Applications Group
SiTel Semiconductor BV

                 reply	other threads:[~2011-02-28  8:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4D6B5988.70406@sitelsemi.com \
    --to=nikolaos.korkakakis@sitelsemi.com \
    --cc=korkakak@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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