Home » Mailing list archives » linux-kernel » 2008 » May » 20

RE: 2.6.25.4-rt2

Previous thread: [AGP] Add a missing via-agp module alias. by Dave Jones on Monday, May 19, 2008 - 6:39 pm. (1 message)

Next thread: [git patches] libata updates by Jeff Garzik on Monday, May 19, 2008 - 6:57 pm. (1 message)
[view original message]
From: Steven Rostedt <rostedt@...>
To: LKML <linux-kernel@...>, RT <linux-rt-users@...>
Cc: Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 6:43 pm

We are pleased to announce the 2.6.25.4-rt2 tree, which can be

downloaded from the location:


  http://rt.et.redhat.com/download/


Information on the RT patch can be found at:


  http://rt.wiki.kernel.org/index.php/Main_Page


Changes since 2.6.25.4-rt1


  - lateral lock stealing (Gregory Haskins)


  - rtmutex rearrange logic (Gregory Haskins)


  - rtmutex remove double xchg (Steven Rostedt)


  - adaptive spinlocks (Gregory Haskins, Sven Deitrich,

                        Peter Morreale, and Steven Rostedt)


  - tsc fixage (Thomas Gleixner)


to build a 2.6.25.4-rt2 tree, the following patches should be applied:


  http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.tar.bz2

  http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.25.4.bz2

  http://rt.et.redhat.com/download/patch-2.6.25.4-rt2.bz2


And like always, my RT version of Matt Mackall's ketchup will get this

for you nicely:


  http://people.redhat.com/srostedt/rt/tools/ketchup-0.9.8-rt3


The broken out patches are also available.


-- Steve


--
[view original message]
From: Kasper Sandberg <lkml@...>
To: Steven Rostedt <rostedt@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 8:19 pm

<snip>


I have just tested this, and it breaks jackd horribly, no matter the

settings, jack ALWAYS underruns.


--
[view original message]
From: Steven Rostedt <rostedt@...>
To: Kasper Sandberg <lkml@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 8:49 pm

Also, could you try 2.6.24.7-rt7.


Thanks,


-- Steve


--
[view original message]
From: Steven Rostedt <rostedt@...>
To: Kasper Sandberg <lkml@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 8:48 pm

Did it work with 2.6.25.4-rt1?


Also could you try this:


 # sysctl kernel.sched_nr_migrate = 4


or try 2.


Thanks,


-- Steve


--
[view original message]
From: Kasper Sandberg <lkml@...>
To: Steven Rostedt <rostedt@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 8:49 pm

I do not know - this is a very new box, and first time i run realtime

I am afraid i do not have this proc entry.


my .config is as follows:

#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.25.4-rt2

# Tue May 20 01:59:59 2008

#

CONFIG_64BIT=y

# CONFIG_X86_32 is not set

CONFIG_X86_64=y

CONFIG_X86=y

CONFIG_DEFCONFIG_LIST="arch/x86/configs/x86_64_defconfig"

# CONFIG_GENERIC_LOCKBREAK is not set

CONFIG_GENERIC_TIME=y

CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_CLOCKSOURCE_WATCHDOG=y

CONFIG_GENERIC_CLOCKEVENTS=y

CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

CONFIG_LOCKDEP_SUPPORT=y

CONFIG_STACKTRACE_SUPPORT=y

CONFIG_HAVE_LATENCYTOP_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_FAST_CMPXCHG_LOCAL=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

CONFIG_GENERIC_HWEIGHT=y

# CONFIG_GENERIC_GPIO is not set

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

CONFIG_RWSEM_GENERIC_SPINLOCK=y

CONFIG_ASM_SEMAPHORES=y

# CONFIG_ARCH_HAS_ILOG2_U32 is not set

# CONFIG_ARCH_HAS_ILOG2_U64 is not set

CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y

CONFIG_GENERIC_CALIBRATE_DELAY=y

CONFIG_GENERIC_TIME_VSYSCALL=y

CONFIG_ARCH_HAS_CPU_RELAX=y

CONFIG_HAVE_SETUP_PER_CPU_AREA=y

CONFIG_ARCH_HIBERNATION_POSSIBLE=y

CONFIG_ARCH_SUSPEND_POSSIBLE=y

CONFIG_ZONE_DMA32=y

CONFIG_ARCH_POPULATES_NODE_MAP=y

CONFIG_AUDIT_ARCH=y

CONFIG_ARCH_SUPPORTS_AOUT=y

CONFIG_GENERIC_HARDIRQS=y

CONFIG_GENERIC_IRQ_PROBE=y

CONFIG_GENERIC_PENDING_IRQ=y

CONFIG_X86_SMP=y

CONFIG_X86_64_SMP=y

CONFIG_X86_HT=y

CONFIG_X86_TRAMPOLINE=y

# CONFIG_KTIME_SCALAR is not set


#

# General setup

#

CONFIG_EXPERIMENTAL=y

CONFIG_LOCK_KERNEL=y

CONFIG_INIT_ENV_ARG_LIMIT=32

CONFIG_LOCALVERSION=""

CONFIG_LOCALVERSION_AUTO=y

CONFIG_SWAP=y

CONFIG_SYSVIPC=y

CONFIG_SYSVIPC_SYSCTL=y

CONFIG_POSIX_MQUEUE=y

CONFIG_BSD_PROCESS_ACCT=y

# CONFIG_BSD_PROCESS_ACCT_V3 is not set

# CONFIG_TASKSTATS is not set

# CONFIG_AUDIT is not set

CONFIG_IKCONFIG=y

CONFIG_IKCONFIG_PROC=y

CONFIG_LOG_BUF_SHIFT=1...
[ message continues ]
[view original message]
From: Steven Rostedt <rostedt@...>
To: Kasper Sandberg <lkml@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 9:21 pm

You need to set SCHED_DEBUG which is dependent on DEBUG_KERNEL.


-- Steve


--
[view original message]
From: Kasper Sandberg <lkml@...>
To: Steven Rostedt <rostedt@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 7:19 pm

Forgive me if i ask an obvious stupid question. But what is the status

of this -rt tree for .25 in relation with the BKL stuff?


--
[view original message]
From: Steven Rostedt <rostedt@...>
To: Kasper Sandberg <lkml@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 7:44 pm

Well, the BKL is still a semaphore in 25.


For my hackbench runs, I have:


[root@bxrhel51 c]# cat hack-test-2.6.25.4-rt2

Time: 4.937

Time: 4.842

Time: 4.877

Time: 4.905

Time: 4.924

Time: 4.781

Time: 4.927

Time: 4.871

Time: 5.181

Time: 4.866


Which is a bit slower than 2.6.24.7-rt7:


[root@bxrhel51 c]# cat hack-test-2.6.24.7-rt7

Time: 4.789

Time: 4.824

Time: 4.807

Time: 4.867

Time: 4.802

Time: 4.799

Time: 4.823

Time: 4.855

Time: 4.873

Time: 4.833


But then I checked the base kernels themselves:


[root@bxrhel51 c]# cat hack-test-2.6.24.7

Time: 3.817

Time: 3.921

Time: 3.887

Time: 3.920

Time: 3.874

Time: 3.858

Time: 3.912

Time: 3.926

Time: 3.888

Time: 3.901


[root@bxrhel51 c]# cat hack-test-2.6.25.4

Time: 6.225

Time: 6.319

Time: 6.257

Time: 6.534

Time: 6.077

Time: 6.787

Time: 6.927

Time: 6.218

Time: 5.929

Time: 6.554


Where there's a regression somewhere. For 25, the RT patch is actually

*better* than mainline!


So I was thinking it had to do with the BKL regression, and then I ran:


[root@bxrhel51 c]# cat hack-test-2.6.26-rc3

Time: 6.789

Time: 7.123

Time: 6.197

Time: 5.496

Time: 6.708

Time: 5.609

Time: 6.679

Time: 6.206

Time: 6.351

Time: 5.969


Here it is no better, and the BKL has been converted into a spin lock.


But I'm very much busy working on -rt right now to dig deeper into this

regression.


-- Steve


--
[view original message]
From: MA QING A <Qing.a.Ma@...>
To: Steven Rostedt <rostedt@...>, Kasper Sandberg <lkml@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: RE: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 8:44 pm

Forgive me to ask a stupid question.

Why using the 24 mainline kernel, the time is less than using the rt-patched kernel?


-----Original Message-----

From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Steven Rostedt

Sent: 2008年5月20日 7:44

To: Kasper Sandberg

Cc: LKML; RT; Ingo Molnar; Thomas Gleixner

Subject: Re: 2.6.25.4-rt2


Well, the BKL is still a semaphore in 25.


For my hackbench runs, I have:


[root@bxrhel51 c]# cat hack-test-2.6.25.4-rt2

Time: 4.937

Time: 4.842

Time: 4.877

Time: 4.905

Time: 4.924

Time: 4.781

Time: 4.927

Time: 4.871

Time: 5.181

Time: 4.866


Which is a bit slower than 2.6.24.7-rt7:


[root@bxrhel51 c]# cat hack-test-2.6.24.7-rt7

Time: 4.789

Time: 4.824

Time: 4.807

Time: 4.867

Time: 4.802

Time: 4.799

Time: 4.823

Time: 4.855

Time: 4.873

Time: 4.833


But then I checked the base kernels themselves:


[root@bxrhel51 c]# cat hack-test-2.6.24.7

Time: 3.817

Time: 3.921

Time: 3.887

Time: 3.920

Time: 3.874

Time: 3.858

Time: 3.912

Time: 3.926

Time: 3.888

Time: 3.901


[root@bxrhel51 c]# cat hack-test-2.6.25.4

Time: 6.225

Time: 6.319

Time: 6.257

Time: 6.534

Time: 6.077

Time: 6.787

Time: 6.927

Time: 6.218

Time: 5.929

Time: 6.554


Where there's a regression somewhere. For 25, the RT patch is actually

*better* than mainline!


So I was thinking it had to do with the BKL regression, and then I ran:


[root@bxrhel51 c]# cat hack-test-2.6.26-rc3

Time: 6.789

Time: 7.123

Time: 6.197

Time: 5.496

Time: 6.708

Time: 5.609

Time: 6.679

Time: 6.206

Time: 6.351

Time: 5.969


Here it is no better, and the BKL has been converted into a spin lock.


But I'm very much busy working on -rt right now to dig deeper into this

regression.


-- Steve


--


--
[view original message]
From: Steven Rostedt <rostedt@...>
To: MA QING A <Qing.a.Ma@...>
Cc: Kasper Sandberg <lkml@...>, LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: RE: 2.6.25.4-rt2
Date: Tuesday, May 20, 2008 - 12:37 am

The test I used is a performance test, not a latency test. An RTOS

(Real-time Operating System) will sacrifice performance to achieve

determinism (low latencies). Several key features to an RT system usually

come with a performance cost.


A non RT system will perform 99% of the time faster than an RTOS. But all

it takes is that one time to miss a deadline to make an RT system crash.

An RTOS may be slightly slower, but it will not have those outliers that a

normal desktop system would have.


So getting back to your question.  Hackbench runs a bunch of stuff and

times how long it took to do so. It stresses the system quite a bit. The

lower the number the better. Given that hackbench is not checking for

latency, but only shear perforance, it is expected that hackbench will run

better on a non RT system.


Now, a test like cyclictest that measures latencies will show the benefits

of realtime.  The kernel with the RT patch can measure 65 microsecond

latencies for response times even while running hackbench. The vanilla

kernel would measure a few milliseconds response times running the same

test.


-- Steve


--
[view original message]
From: MA QING A <Qing.a.Ma@...>
To: Steven Rostedt <rostedt@...>
Cc: Kasper Sandberg <lkml@...>, LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: RE: 2.6.25.4-rt2
Date: Tuesday, May 20, 2008 - 12:59 am

Thanks very much for your explanation

At the very beginning I thought the Hackbench was a latency tools, so I was very surprised to see such result.


But there's another question. When I choose the Complete Preemption -Real Time  configuration, it's recommended to choose Timer Frequency ---> 1000Mhz to improve the cpu performance, does it mean cpu will cost much more during the thread context switch? Or I should choose 100Mhz in order to decrease the thread context switch and get a better performance?

Which one should I choose? Or any useful tools can tell me the differences.


Any opinion appreciated

Thanks


Really Thanks again


-----Original Message-----

From: Steven Rostedt [mailto:rostedt@goodmis.org]

Sent: 2008年5月20日 12:37

To: MA QING A

Cc: Kasper Sandberg; LKML; RT; Ingo Molnar; Thomas Gleixner

Subject: RE: 2.6.25.4-rt2


The test I used is a performance test, not a latency test. An RTOS

(Real-time Operating System) will sacrifice performance to achieve

determinism (low latencies). Several key features to an RT system usually

come with a performance cost.


A non RT system will perform 99% of the time faster than an RTOS. But all

it takes is that one time to miss a deadline to make an RT system crash.

An RTOS may be slightly slower, but it will not have those outliers that a

normal desktop system would have.


So getting back to your question.  Hackbench runs a bunch of stuff and

times how long it took to do so. It stresses the system quite a bit. The

lower the number the better. Given that hackbench is not checking for

latency, but only shear perforance, it is expected that hackbench will run

better on a non RT system.


Now, a test like cyclictest that measures latencies will show the benefits

of realtime.  The kernel with the RT patch can measure 65 microsecond

latencies for response times even while running hackbench. The vanilla

kernel would measure a few milliseconds response times running the same

test.


-- Steve


--
[view original message]
From: Steven Rostedt <rostedt@...>
To: MA QING A <Qing.a.Ma@...>
Cc: Kasper Sandberg <lkml@...>, LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: RE: 2.6.25.4-rt2
Date: Tuesday, May 20, 2008 - 9:54 am

Hi,


[

  It seems that you may be new to the lists, so I will let you know,

  please do not top post. It is appropriate to either bottom post or

  better yet, inline reply. See http://en.wikipedia.org/wiki/Posting_style

]


I'm not sure where you read that. With the introduction of high-resolution

timers, the HZ value isn't that important anymore. Things that might use

select or poll as timeouts will still be at the HZ frequency, but other

code that uses proper timer API will still react well.


Matters what you are doing. Try out different values yourself and see what

you find is the best. You can also report your findings if you want.


Cheers,


-- Steve


--
[view original message]
From: Kasper Sandberg <lkml@...>
To: Steven Rostedt <rostedt@...>
Cc: LKML <linux-kernel@...>, RT <linux-rt-users@...>, Ingo Molnar <mingo@...>, Thomas Gleixner <tglx@...>
Subject: Re: 2.6.25.4-rt2
Date: Monday, May 19, 2008 - 7:43 pm

I just asked because i have read a bit of the discussion, and have

personally noticed that there is no option to "preempt the bkl" in

my .25 configuration


--
Previous thread: [AGP] Add a missing via-agp module alias. by Dave Jones on Monday, May 19, 2008 - 6:39 pm. (1 message)

Next thread: [git patches] libata updates by Jeff Garzik on Monday, May 19, 2008 - 6:57 pm. (1 message)