All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Priority Inheritance Test (Real-Time Preemption)
Date: Fri, 26 Nov 2004 02:08:41 +0100	[thread overview]
Message-ID: <20041126010841.GA3563@elte.hu> (raw)
In-Reply-To: <Pine.OSF.4.05.10411252305040.25041-100000@da410.ifa.au.dk>


* Esben Nielsen <simlo@phys.au.dk> wrote:

> I am running on -31-7 kernel now - it takes quite some time to run with
> the runall.sh script with 100000 samples per point so I don't have full
> data yet. [...]

btw., do you really need 100,000 samples to get statistically stable
results? I've been running with 1000 samples and it was already more
than usable - i'd say 3000-5000 samples ought to be more than enough. 

> But the bounds look like
> depth observed bound  theoretical
>    1        1 ms          1 ms
>    2        3 ms          2 ms      :-(

are you sure the theoretical limit is 2 msec? I think it's 3 msec, for
the following reason:

there are two types of nonprivileged-task lock sequences allowed in the
2-deep case:

	spin_lock(&lock2);
	spin_lock(&lock1);
	... loop for 1 msec ...
	spin_unlock(&lock1);
	spin_unlock(&lock2);

or:
	spin_lock(&lock1);
	... loop for 1 msec ...
	spin_unlock(&lock1);

now, with the above locking, the worst case scenario is the following
one, in chronological order [task A and B are unprivileged, RT is the
highprio task]:

	task-A			task-B			task-RT

	spin_lock(&lock2);
	[ gets lock2 ]
				spin_lock(&lock1);
				[ gets lock1 ]
							spin_lock(&lock2);
							[ boosts task-A ]
							[ waits ]
	[ gets RT prio ]				.
	spin_lock(&lock1);				.
	[ boosts task-B ]				.
	[ waits ]					.
	.			[ gets RT prio ]	.
	.			[ 1 msec loop ]		.
	.			spin_unlock(&lock1);	.
	[ gets lock 1 ]					.
				spin_lock(&lock1);	.
				[ waits ]		.
	[ 1 msec loop ]		.			.
	spin_unlock(&lock1);	.			.
				[ gets lock1 ]		.
	spin_unlock(&lock2);				.
							[ gets lock2 ]
							spin_lock(&lock1);
							[ boosts task-B ]
							[ waits ]
				[ 1 msec loop ]		.
				spin_unlock(&lock1);	.
							[ gets lock1 ]


the additional 1 msec comes in because the RT task might be blocking on
a task that _itself_ has to wait 1 msec to get its second lock. So we
have 3 msec of maximum waiting altogether.

the additional +1 msec comes from the fact that 1-deep lock/unlock of
lock1 is an allowed operation too - 2 msec would be the limit if the
only sequence is the 2-deep one.

so i think the numbers, at least in the 2-deep case, are quite close to
the theoretical boundary.

agreed?

	Ingo

  reply	other threads:[~2004-11-26 23:15 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-21 20:29 Priority Inheritance Test (Real-Time Preemption) Esben Nielsen
2004-11-22  0:27 ` Ingo Molnar
2004-11-23 13:34   ` Ingo Molnar
2004-11-23 15:47     ` Esben Nielsen
2004-11-23 23:03     ` Esben Nielsen
2004-11-24  3:42       ` Ingo Molnar
2004-11-24  7:51         ` Ingo Molnar
2004-11-24  8:07       ` Ingo Molnar
2004-11-24  8:33         ` Esben Nielsen
2004-11-24  9:55           ` Ingo Molnar
2004-11-24 10:18       ` Ingo Molnar
2004-11-25 15:46         ` Esben Nielsen
2004-11-25 16:58           ` Ingo Molnar
2004-11-25 16:08             ` Esben Nielsen
2004-11-25 17:14               ` Ingo Molnar
2004-11-25 22:08             ` Esben Nielsen
2004-11-26  1:08               ` Ingo Molnar [this message]
2004-11-26  0:34                 ` Ingo Molnar
2004-11-26  0:37                   ` Ingo Molnar
2004-11-26  8:52                     ` Esben Nielsen
2004-11-26 16:26                 ` Esben Nielsen
2004-11-26 20:41                   ` Ingo Molnar
2004-11-26 21:05                     ` Ingo Molnar
2004-11-27 23:05                       ` Esben Nielsen
2004-11-28  8:42                         ` Ingo Molnar
2004-11-28 15:55                           ` Esben Nielsen
2004-11-29  9:59                             ` Ingo Molnar
2004-11-29 15:07                               ` Esben Nielsen
2004-11-29 15:56                                 ` Ingo Molnar
2004-11-29 15:57                                   ` Ingo Molnar
2004-11-29 16:50                                     ` Esben Nielsen
2004-11-30  8:49                                       ` Ingo Molnar
2004-11-22  9:23 ` Bill Huey
2004-11-22 12:37   ` Ingo Molnar
2004-11-22 21:25     ` Bill Huey
2004-11-22 14:16   ` john cooper
2004-11-22 15:24     ` Ingo Molnar
2004-11-23  1:19       ` john cooper
2004-11-23  8:13         ` Esben Nielsen
2004-11-23  9:21         ` Ingo Molnar
2004-11-22 21:30     ` Bill Huey
2004-11-23  1:34       ` john cooper
2004-11-22 16:12   ` Esben Nielsen

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=20041126010841.GA3563@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simlo@phys.au.dk \
    /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.