From: Steven Rostedt <rostedt@goodmis.org>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: Ingo Molnar <mingo@elte.hu>, Rui Nuno Capela <rncbc@rncbc.org>,
"K.R. Foley" <kr@cybsft.com>,
Fernando Lopez-Lezcano <nando@ccrma.stanford.edu>,
Mark Johnson <Mark_H_Johnson@RAYTHEON.COM>,
Amit Shah <amit.shah@codito.com>,
Karsten Wiese <annabellesgarden@yahoo.de>,
Bill Huey <bhuey@lnxw.com>, Adam Heath <doogie@debian.org>,
emann@mrv.com, Gunther Persoons <gunther_persoons@spymac.com>,
LKML <linux-kernel@vger.kernel.org>,
Florian Schmidt <mista.tapas@gmx.net>,
Lee Revell <rlrevell@joe-job.com>,
Shane Shrybman <shrybman@aei.ca>,
Thomas Gleixner <tglx@linutronix.de>,
Michal Schmidt <xschmi00@stud.feec.vutbr.cz>
Subject: Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)
Date: Mon, 27 Dec 2004 11:39:20 -0500 [thread overview]
Message-ID: <1104165560.20042.108.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.OSF.4.05.10412271655270.18818-100000@da410.ifa.au.dk>
On Mon, 2004-12-27 at 17:23 +0100, Esben Nielsen wrote:
> > > [...]
> >
> > Why just limit to the number of CPUs, but make a configurable limit. I
> > would say the default may be 2*CPUs. Reason being is that once you
> > limit the number of readers, you just bound the down_write. Even if
> > number of readers allowed is 100, the down_write is now bound to
> > O(ceil(n/#cpus)) as you said, but now n is known. Make a
> > CONFIG_ALLOWED_READERS or something to that affect, and it would be easy
> > to see what is a good optimal configuration (assuming you have the
> > proper tests).
> >
> I agree with you that it ought to be configureable. But if you set it to
> something like 100 it is _not_ deterministic in practise. I.e. during your
> tests you have a really hard time making 100 readers at the critical
> point. Most likely you only have a handfull. Then when you deploy the
> system where you might have a webserver presenting data read under a
> rw-lock is overloaded spawns 100 worker tasks. Bang! Your RT application
> doesn't run!
> It doesn't help you to have something bounded if the bound is insanely
> high such you never reach it in tests. And if you try to calculate the
> worst case scenarious for such a system you would find it doesn't
> schedule. I.e. you have to buy a bigger CPU or do some other drastic
> thing!
>
I wasn't saying that 100 was a GOOD number, but that was just an
example. I'm one of those that don't like the program, application,
kernel, to limit you on how you want to shoot yourself in the foot. But
always have the default set to something that prevents the idiot from
doing something too idiotic.
> A limit like 1 reader per CPU on the other hand behaves like a
> normal mutex priority inheritance wrt. determinism. And it scales like the
> stock Linux rw-lock which in practise is also limited to 1 task per CPU as
> preemption is switched off :-)
>
Do you think 2/cpu is too high? I'd figure that reads usually happen way
more than writes, and writes can usually last longer than reads, but
having the default to two, you can test your code, on a UP.
> > [...]
> > I have two SMP machines that I can test on, unfortunately, they both
> > have NVIDIA cards, so I cant use them with X, unless I go back to the
> > default driver. Which I would do, but I really like the 3d graphics ;-)
> >
>
> Well, these kind of things isn't something you want to combine with 3d
> graphics right away anyway!
> I have even had problems with crashing on 2.4.xx with a NVidia and
> hyperthreading on a machine I helped install :-(
> I am afraid NVidia cards and preempt realtime is far in the future :-(
>
Actually, I've had some success with NVIDIA on all my kernels (except of
course the realtime ones). Unfortunately, there are the little crashes
here and there, but those usually happen with screen savers so I don't
lose data. I just come back to the machine and say WTF, I'm at a login
prompt! I am one of those that save everything within seconds of
modifying, and use subversion commits like crazy :-)
-- Steve
next prev parent reply other threads:[~2004-12-27 16:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-10 17:49 [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15 Mark_H_Johnson
2004-12-10 21:09 ` Ingo Molnar
2004-12-10 21:12 ` Ingo Molnar
2004-12-10 21:24 ` Ingo Molnar
2004-12-13 0:16 ` Fernando Lopez-Lezcano
2004-12-13 6:47 ` Ingo Molnar
2004-12-14 0:46 ` Fernando Lopez-Lezcano
2004-12-14 4:42 ` K.R. Foley
2004-12-14 8:47 ` Rui Nuno Capela
2004-12-14 11:35 ` Ingo Molnar
2004-12-27 14:35 ` Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15) Esben Nielsen
2004-12-27 15:27 ` Steven Rostedt
2004-12-27 16:23 ` Esben Nielsen
2004-12-27 16:39 ` Steven Rostedt [this message]
2004-12-27 21:06 ` Bill Huey
2004-12-27 21:48 ` Valdis.Kletnieks
2004-12-28 21:59 ` Lee Revell
2005-01-04 15:25 ` Andrew McGregor
2004-12-28 21:42 ` Lee Revell
2005-01-28 7:38 ` Ingo Molnar
2005-01-28 11:56 ` William Lee Irwin III
2005-01-28 15:28 ` Ingo Molnar
2005-01-28 15:55 ` William Lee Irwin III
2005-01-28 16:16 ` Ingo Molnar
2005-01-28 19:18 ` Trond Myklebust
2005-01-28 19:45 ` Ingo Molnar
2005-01-28 23:25 ` Bill Huey
2005-01-28 21:13 ` Lee Revell
2005-01-30 22:03 ` Esben Nielsen
2005-01-30 23:59 ` Kyle Moffett
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=1104165560.20042.108.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=Mark_H_Johnson@RAYTHEON.COM \
--cc=amit.shah@codito.com \
--cc=annabellesgarden@yahoo.de \
--cc=bhuey@lnxw.com \
--cc=doogie@debian.org \
--cc=emann@mrv.com \
--cc=gunther_persoons@spymac.com \
--cc=kr@cybsft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mista.tapas@gmx.net \
--cc=nando@ccrma.stanford.edu \
--cc=rlrevell@joe-job.com \
--cc=rncbc@rncbc.org \
--cc=shrybman@aei.ca \
--cc=simlo@phys.au.dk \
--cc=tglx@linutronix.de \
--cc=xschmi00@stud.feec.vutbr.cz \
/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.