Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Post by Steven Ros » Wed, 29 Dec 2004 00:40:59


n Mon, 2004-12-27 at 15:35 +0100, Esben Nielsen wrote:

I think they are on vacation :-)


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 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 ;-)


-- Steve

--
Steven Rostedt
Senior Engineer
Kihon Technologies

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 
 
 

Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Post by Steven Ros » Wed, 29 Dec 2004 01:50:24

n Mon, 2004-12-27 at 17:23 +0100, Esben Nielsen wrote:



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.


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.


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

 
 
 

Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Post by Lee Revel » Thu, 30 Dec 2004 06:50:13


Not necessarily. I am sure many of Nvidia's potential customers want to
do high end simulation and that requires an RT capable OS and good
graphics hardware. If many people end up using RT preempt for high end
simulator applications, like several who have posted on this list, then
it seems like it would a good fit.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Post by Lee Revel » Thu, 30 Dec 2004 07:10:05


Yes, an RTOS certainly helps. Otherwise you cannot guarantee a minimum
frame rate - if a long running disk ISR fires then you are screwed,
because jsut as with low latency audio you have a SCHED_FIFO userspace
process that is feeding data to the GPU at a constant rate. Its a worse
problem with audio because you absolutely cannot drop a frame or you
will hear it. With video it's likely to be imperceptible.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Post by Trond Mykl » Sun, 30 Jan 2005 05:00:12

fr den 28.01.2005 Klokka 08:38 (+0100) skreiv Ingo Molnar:


If you do have a highest interrupt case that causes all activity to
block, then rwsems may indeed fit the bill.

In the NFS client code we may use rwsems in order to protect stateful
operations against the (very infrequently used) server reboot recovery
code. The point is that when the server reboots, the server forces us to
block *all* requests that involve adding new state (e.g. opening an
NFSv4 file, or setting up a lock) while our client and others are
re-establishing their existing state on the server.

IOW: If you are planning on converting rwsems into a semaphore, you will
screw us over most royally, by converting the currently highly
infrequent scenario of a single task being able to access the server
into the common case.

Cheers,
Trond
--
Trond Myklebust < XXXX@XXXXX.COM >

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Real-time rw-locks ( [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

Post by Lee Revel » Sun, 30 Jan 2005 06:20:08


Hmm, when I was an ISP sysadmin I used to use this all the time. NFS
mounts from the BSD/OS clients would start to act up under heavy web
server load and the cleanest way to get them to recover was to simulate
a reboot on the NetApp. Of course Linux clients were unaffected, they
were just along for the ride ;-)

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/