Tom Cook | 4 Apr 17:37 2012
Picon

NVIDIA binary driver with rt patch

I'm quite new to linux-rt.  I'm trying to get a usable RT kernel on an
Ubuntu 11.10 system.  It has an nVidia Quadro NVS 285 video card and
I'm trying to get the binary drivers working, too.

I've built the 3.0.25 kernel with the rt44 patcheset applied.  I've
also modified it slightly so that migrate_enable, migrate_disable and
__init_rt_mutex are exported using EXPORT_SYMBOL rather than
EXPORT_SYMBOL_GPL (note I am aware of the legal issues surrounding
this and won't be distributing the resulting kernel or source).  I've
then patched the nVidia driver source, replacing atomic_spinlock with
raw_spinlock, down/up with mutex_lock/mutex_unlock and semaphores with
mutexes.

The resulting system runs and has quite good RT performance (max
latency <20us reported by cyclictest, at least on short tests with
full Ubuntu desktop running).  However, the performance of X is dire -
I get about two screen updates per second.  The mouse still moves
smoothly, but everything else only updates once or twice per second.
It seems to be something quite far down the graphics processing chain
that is slow, not individual operations - for instance, opening a page
in Firefox doesn't take much longer than usual, it's just that I get
no response at all for nearly a second and then the rendered page
appears.  It's like the screen is rendered into a buffer very fast but
then flipping that buffer to the display is very slow.

Does anyone have any suggestions for what might cause this or tools
for tracking down where the problem comes from?  I've spent a couple
of days googling now with no success.

Thanks for any help,
(Continue reading)

Steven Rostedt | 5 Apr 02:09 2012

[ANNOUNCE] 3.0.27-rt46


Dear RT Folks,

I'm pleased to announce the 3.0.27-rt46 stable release.

This release is just an update to the new stable 3.0.27 version
and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: 6215991af1dca371ae7585d38df0422c513dfef2

Or to build 3.0.27-rt46 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.27.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.27-rt46.patch.xz

Enjoy,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Thomas Schauss | 5 Apr 10:50 2012
Picon

Re: NVIDIA binary driver with rt patch

On 04/04/2012 05:37 PM, Tom Cook wrote:
> I'm quite new to linux-rt.  I'm trying to get a usable RT kernel on an
> Ubuntu 11.10 system.  It has an nVidia Quadro NVS 285 video card and
> I'm trying to get the binary drivers working, too.
>
> I've built the 3.0.25 kernel with the rt44 patcheset applied.  I've
> also modified it slightly so that migrate_enable, migrate_disable and
> __init_rt_mutex are exported using EXPORT_SYMBOL rather than
> EXPORT_SYMBOL_GPL (note I am aware of the legal issues surrounding
> this and won't be distributing the resulting kernel or source).  I've
> then patched the nVidia driver source, replacing atomic_spinlock with
> raw_spinlock, down/up with mutex_lock/mutex_unlock and semaphores with
> mutexes.
>
> The resulting system runs and has quite good RT performance (max
> latency<20us reported by cyclictest, at least on short tests with
> full Ubuntu desktop running).  However, the performance of X is dire -
> I get about two screen updates per second.  The mouse still moves
> smoothly, but everything else only updates once or twice per second.
> It seems to be something quite far down the graphics processing chain
> that is slow, not individual operations - for instance, opening a page
> in Firefox doesn't take much longer than usual, it's just that I get
> no response at all for nearly a second and then the rendered page
> appears.  It's like the screen is rendered into a buffer very fast but
> then flipping that buffer to the display is very slow.
>
> Does anyone have any suggestions for what might cause this or tools
> for tracking down where the problem comes from?  I've spent a couple
> of days googling now with no success.
>
(Continue reading)

Juri Lelli | 7 Apr 09:52 2012
Picon

SCHED_DEADLINE v4

Hello everyone,

This is to inform you that a new version of the SCHED_DEADLINE patchset
is out (v4). What follows is an excerpt of the overview (00/16) messsage
sent on LKML, you can find the thread here:
https://lkml.org/lkml/2012/4/6/39

[...]
Just to recap, the patchset introduces a new deadline based real-time
task scheduling policy --called SCHED_DEADLINE-- with bandwidth
isolation (aka "resource reservation") capabilities. It now supports
global/clustered multiprocessor scheduling through dynamic task
migrations.

  From the previous releases[1]:
   - all the comments and the fixes coming from the reviews we got have
     been considered and applied;
   - better handling of rq selection for dynamic task migration, by means
     of a cpupri equivalent for -deadline tasks (cpudl). The mechanism
     is simple and straightforward, but showed nice performance figures[2].
   - this time we sit on top of PREEMPT_RT (3.2.13-rt23); we continue to aim
     at mainline inclusion, but we also see -rt folks as immediate and
     interested users.

Still missing/incomplete:
   - (c)group based bandwidth management, and maybe scheduling. It seems
     some more discussion on what precisely we want is *really* needed
     for this point;
   - bandwidth inheritance (to replace deadline/priority inheritance).
     What's in the patchset is just very few more than a simple
(Continue reading)

Raz | 10 Apr 09:06 2012
Picon

opprofile support

Hello

Can anyone explain why oprofile is disabled in preempt rt ?
What is need to be done to get profiling support ?
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thomas Gleixner | 10 Apr 16:42 2012
Picon

[ANNOUNCE] 3.2.14-rt24

Dear RT Folks,

I'm pleased to announce the 3.2.14-rt24 release.

This is my last release based on 3.2. I'm handing the 3.2-rt series
over to Steven and move on to 3.4.

The RT patch against 3.2.14 can be found here:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.14-rt24.patch.xz

The split quilt queue is available at:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patches-3.2.14-rt24.tar.xz

Enjoy,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thomas Gleixner | 10 Apr 16:46 2012
Picon

[ANNOUNCE] 3.4-rc2-rt1

Dear RT Folks,

I'm pleased to announce the 3.4-rc2-rt1 release.

This is a straight forward update of the 3.2 series to 3.4-rc2. It's
slightly smaller than the 3.2 series. I hope to stabilize it fast so I
can concentrate on shuffling more parts of RT into 3.5.

The RT patch against 3.4-rc2-rt1 can be found here:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4-rc2-rt1.patch.xz

The split quilt queue is available at:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patches-3.4-rc2-rt1.tar.xz

Enjoy,

	tglx
---
Index: linux-3.2/fs/autofs4/autofs_i.h
===================================================================
--- linux-3.2.orig/fs/autofs4/autofs_i.h
+++ linux-3.2/fs/autofs4/autofs_i.h
 <at>  <at>  -34,6 +34,7  <at>  <at> 
 #include <linux/sched.h>
 #include <linux/mount.h>
 #include <linux/namei.h>
+#include <linux/delay.h>
 #include <asm/current.h>
(Continue reading)

Arnd Bergmann | 10 Apr 16:58 2012
Picon

Re: [ANNOUNCE] 3.4-rc2-rt1

On Tuesday 10 April 2012, Thomas Gleixner wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.4-rc2-rt1 release.
> 
> This is a straight forward update of the 3.2 series to 3.4-rc2. It's
> slightly smaller than the 3.2 series. I hope to stabilize it fast so I
> can concentrate on shuffling more parts of RT into 3.5.
> 
> The RT patch against 3.4-rc2-rt1 can be found here:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4-rc2-rt1.patch.xz
> 
> 
> The split quilt queue is available at:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patches-3.4-rc2-rt1.tar.xz
> 
> Enjoy,
> 
> 	tglx
> ---
> Index: linux-3.2/fs/autofs4/autofs_i.h
> ===================================================================
> --- linux-3.2.orig/fs/autofs4/autofs_i.h
> +++ linux-3.2/fs/autofs4/autofs_i.h

I guess the patch you attached here with this diffstat

 block/blk-iopoll.c      |    3 +++
(Continue reading)

Thomas Gleixner | 10 Apr 17:02 2012
Picon

Re: [ANNOUNCE] 3.4-rc2-rt1

On Tue, 10 Apr 2012, Arnd Bergmann wrote:
> On Tuesday 10 April 2012, Thomas Gleixner wrote:
>  net/rds/ib_rdma.c       |    3 ++-
>  13 files changed, 72 insertions(+), 15 deletions(-)
> 
> is not the one you describe above but the one for the 3.2.14-rt24 release,
> right? Otherwise it would be considerably smaller compared to 3.2-rt, not
> just a bit ;-)

Someone should forbit copy and paste, really. :)

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steven Rostedt | 10 Apr 21:57 2012

Re: [ANNOUNCE] 3.2.14-rt24

On Tue, 2012-04-10 at 16:42 +0200, Thomas Gleixner wrote:

> This is my last release based on 3.2. I'm handing the 3.2-rt series
> over to Steven and move on to 3.4.

The branch v3.2-rt has been created in:

   git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

It starts with v3.2.14-rt24 with the patches broken out on top of
v3.2.14.

New releases for v3.2-rt will now be kept in this branch and patch files
will be produced similar to the way the v3.0-rt tree is maintained.

This branch will never rebase, and new mainline stable releases will be
merged into this branch. Fixes will be applied on top of the branch. I
will also create a v3.2-rt-rebase branch (and tags) that will allow you
to make broken out patches (like v3.0-rt-rebase) as long as time permits
me to do so.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane