linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Mc Guire <der.herr@hofr.at>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: williams@redhat.com, linux-rt-users@vger.kernel.org,
	C.Emde@osadl.org, tglx@linutronix.de, andi@opentech.at
Subject: Re: [rt-tests][PATCH] align thread wakeup times
Date: Fri, 4 Oct 2013 18:21:39 +0200	[thread overview]
Message-ID: <20131004162139.GD9752@opentech.at> (raw)
In-Reply-To: <524ED838.2060500@linutronix.de>

On Fri, 04 Oct 2013, Sebastian Andrzej Siewior wrote:

> On 10/04/2013 03:33 PM, Nicholas Mc Guire wrote:
> >> I would rather fix current behaviour instead introducing yet another
> >> option. By using -d0 I assume that all threads wakeup at the same time.
> > 
> > Nop they do not -d0 just says that they all use
> > the same period rather than some offset with multiple threads (e.g. -S)
> > 
> >> According to your patch this does not happen due to the thread creating
> >> / starting overhead.
> >> Is there is a reason to keep this "faulty" behavior? If not I would vote
> >> to make this what you suggest the default.
> >>
> > 
> > its not faulty behavior - its a different case
> > in fact we need both.
> > 
> > same period + "random" start time
> > same period + synced start time
> > 
> > it makes a difference on some boxes that is significant.
> 
> So you say with -d0, where d is documented as "distance of thread
> intervals in us", I should not expect that all threads share the exact
> same wakeup time (because their distance is 0)?
>
no why should you - you might want
 
-i 100 -d 50 -A 20

T1 0     100     200     300
T2  20         170
T3   40              240
T4    60                   310

Which is quite a lot different than just stating

that i_1=100 i_2=150, etc... but initial distance "undefined" or random

so in the sense of schedulability tests these are really two seperate
parameters and thus should be configurable independently.

That the current documentation might give the impression that they are
in sync is a bug in the documentation not in the -d implementation.

hofrat
 

  reply	other threads:[~2013-10-04 16:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09  7:29 [rt-tests][PATCH] align thread wakeup times Nicholas Mc Guire
2013-10-04 13:22 ` Sebastian Andrzej Siewior
2013-10-04 13:33   ` Nicholas Mc Guire
2013-10-04 15:01     ` Sebastian Andrzej Siewior
2013-10-04 16:21       ` Nicholas Mc Guire [this message]
2013-10-04 16:35         ` 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=20131004162139.GD9752@opentech.at \
    --to=der.herr@hofr.at \
    --cc=C.Emde@osadl.org \
    --cc=andi@opentech.at \
    --cc=bigeasy@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).