All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Sander <tim@krieglstein.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	rostedt@goodmis.org, John Kacur <jkacur@redhat.com>
Subject: Re: [ANNOUNCE] 4.1.5-rt5 meant to reply to 4.4.1-rt5
Date: Fri, 12 Feb 2016 15:36:16 +0100	[thread overview]
Message-ID: <7138155.u6nNkmxGuH@dabox> (raw)
In-Reply-To: <56BDA0EF.7090503@linutronix.de>

Hi Sebastian

As you got correctly i was talking about 4.4.1-rt5 and not 4.1 i replied to by 
accident.

Am Freitag, 12. Februar 2016, 10:07:59 schrieb Sebastian Andrzej Siewior:
> On 02/12/2016 09:28 AM, Tim Sander wrote:
> > Hi Sebastian
> 
> Hi Tim,
> 
> > Am Sonntag, 16. August 2015, 15:56:30 schrieb Sebastian Andrzej Siewior:
> >> I'm pleased to announce the v4.1.5-rt5 patch set.
> > 
> > I have just tested it with a Altera SoC ARM v7. The latencies seem to have
> > gotten a little bit worse with each release. The first core has always
> > been
> > worse (presumably due to interrupt load) but now it dropped to 111µs (rt5)
> > from 76µs(rt3) and 54µs(rt2).
> 
> in -rt2 we had bug in migrate disable code which means each task was
> running on CPU0. This got partly fixed in -rt3. In -rt3 the scheduler
> could assign a task to CPU1 but the task should stay there for ever.
> This little detail was fixed in -rt5.
> This is one thing that comes to mind.
> Lazy-preempt should have been fixed in -rt3, too. This should not give
> you higher latencies but higher throughput.
> 
> What about rt4? It is only the stable update so you should see here the
> numbers from rt3. If that is true and your numbers are stable it should
> be easy to run git bisect between rt4 and rt5. And looking at
>   https://git.kernel.org/rt/linux-rt-devel/h/v4.4.1-rt5
> the only non-cosmetic change in -rt5 that should affect you is the
> migrate-disable fixup from Mike.
Ok, each run takes a couple of hours so bisecting should take quite some time
but i will give it a try. I started a test with 4.4.1-rt4, if the numbers are 
within the 70µs ballpark bisecting seems the way to go. If the numbers are 
higher i suspect that stable update might have a play here. But we will see.

Best regards
Tim

  reply	other threads:[~2016-02-12 14:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-16 13:56 [ANNOUNCE] 4.1.5-rt5 Sebastian Andrzej Siewior
2016-02-12  8:28 ` Tim Sander
2016-02-12  9:07   ` Sebastian Andrzej Siewior
2016-02-12 14:36     ` Tim Sander [this message]
2016-02-17  8:14     ` Bisect results for 4.4.1-rt[4,5] Tim Sander
2016-02-25 14:06       ` Sebastian Andrzej Siewior
2016-02-25 14:06         ` Sebastian Andrzej Siewior

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=7138155.u6nNkmxGuH@dabox \
    --to=tim@krieglstein.org \
    --cc=bigeasy@linutronix.de \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.