All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai-core@domain.hid
Subject: Re: [Xenomai-core] [PATCH 0/6] Fix, refactor, and optimize xnlock services, v2
Date: Sun, 02 Mar 2008 16:52:19 +0100	[thread overview]
Message-ID: <47CACD33.5000107@domain.hid> (raw)
In-Reply-To: <18378.50046.906228.646119@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi,
>  > 
>  > here comes version 2 of my xnlock rework. Changes since the first
>  > release:
>  > 
>  >  - Moved xnlock_spin out-of-line instead uninlining the irqsave/restore
>  >    services
> 
> The size changes are not as dramatic as with the first version. Did you
> have any chance to test the latency with your first version?

Not under the same conditions (isolated core). In essence, the gain was
less significant (~1 us). I came to the conclusion that this might be
due to some loss related to moving xnlock_put_irqrestore out-of-line (I
think now that function was too small for this).

Instead of further digging into this I decided to address the root of
the issue, ie. bringing down the text size of the pipeline-head
services. So you now have to apply the ipipe patch to achieve both a
text size reduction (almost as good as the original one) AND a code path
length reduction (more important!). Actually, I haven't even done a full
benchmark with this patch applied as well yet, but it is not that
interesting as the runtime advantage is obvious (simply less ops).

> 
>  >  - Beautified xnlock_dbg interface (now only static-inlines)
> 
> Well, I am still not convinced, I still find the debugging version harder
> to read. Is there a problem with implementing the two versions
> separately with a unique #ifdef?

Well, everything is possible. But we would start to duplicate LOC again,
namely both the lock implementations and the debugging services. Just
look at the final system.h and pod.h after applying all patches.

I could try this, but only if it is _really_ desired. I'm convinced it
is the wrong way because I consider the readability and consistency of
the lock implementation more important than its debug code.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

  reply	other threads:[~2008-03-02 15:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-02 11:02 [Xenomai-core] [PATCH 0/6] Fix, refactor, and optimize xnlock services, v2 Jan Kiszka
2008-03-02 15:10 ` Gilles Chanteperdrix
2008-03-02 15:52   ` Jan Kiszka [this message]
2008-03-03 10:06     ` Gilles Chanteperdrix
2008-03-28 18:21       ` Jan Kiszka

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=47CACD33.5000107@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Xenomai-core@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.