Dear RT Folks,
I'm pleased to announce the 3.6.5-rt14 release. 3.6.4-rt12 is an
intermediate release with a few changes. 3.6.5-rt13 is an update to
3.6.5 and 3.6.5-rt14 has a fix for my stupidity to release from the
wrong tree missing a fix for x86-32.
Changes since 3.6.3-rt11:
* Fix the fallout of preempt_lazy
* Add preempt_lazy support for ARM and POWERPC
* Fix a 32bit compile warning which got introduced with the
random fixes.
* Fix a missing lock conversion in the decive tree code
The delta patch against 3.6.4-rt11 is can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.4-rt11-rt12.patch.xz
The RT patch against 3.6.5 can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.5-rt14.patch.xz
The split quilt queue is available at:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.5-rt14.tar.xz
Enjoy,
tglx
[[ANNOUNCE] 3.6.5-rt14] On 01/11/2012 (Thu 21:57) Thomas Gleixner wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.6.5-rt14 release. 3.6.4-rt12 is an
> intermediate release with a few changes. 3.6.5-rt13 is an update to
> 3.6.5 and 3.6.5-rt14 has a fix for my stupidity to release from the
> wrong tree missing a fix for x86-32.
The rt14 content is available at the split queue repo on the master
branch. I've also created a 3.6.5-rt14-fixes branch, which contains:
1) another %cx --> %ecx mismatch warning fix
2) fixes a bogus PREEMPT_LAZE in a select line
3) pointless newline removal fix carried over from 3.6.4-rt11-fixes
All patches are fixed in-place directly within the existing patches
without changing the series file (vs adding a separate patch for
later folding). So they should be a drop in for integration even
if folks aren't using this git repo to provide history tracking.
Patches on the 3.6.5-rt14-fixes pass a basic boot test on x86_32 UP.
For those who didn't catch one of the earlier posts[1] about the split
patch queue repo, it is a history tracking repo of all the releases of
the patches-3.6.X-rtY.tar.xz (X=gregkh stable, Y=rt version).
Having the history repo allows you to track how each patch evolves,
how the ordering changes and so on.
You can use it just like a split queue tarball, in that you git am (or
git quiltimport) the patches in the repo onto a gregkh stable tree, and
then you can run "git blame path/to/somefile" to see seamless history
across rt and back into stable/mainline as to who mangled what lines.
The plus is, that rather than download and untar each time, you just go
into where you've cloned this repo, and issue a "git pull" to get the
latest update. Go to your kernel tree, checkout the appropriate gregkh
stable baseline and reapply the patches and you are done.
Folks can browse the repo at:
http://git.kernel.org/?p=linux/kernel/git/paulg/3.6-rt-patches.git
Paul.
[1] http://permalink.gmane.org/gmane.linux.rt.user/8864
---
The following changes since commit 3f2b22edd602ef42f77abf345a0a777ccd4033ac:
patches-3.6.5-rt14.tar.xz (2012-11-02 11:52:35 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/3.6-rt-patches.git v3.6.5-rt14-fixes
for you to fetch changes up to a1221218459505df9a2d6c63d29432c637804a91:
x86_32: fix %cx -> %ecx mismatch on testl (2012-11-02 12:27:51 -0400)
----------------------------------------------------------------
Paul Gortmaker (3):
preempt-lazy-support.patch: delete trailing newline addition
fix bogus HAVE_PREEMPT_LAZE in preempt-lazy-support.patch
x86_32: fix %cx -> %ecx mismatch on testl
preempt-lazy-support.patch | 7 ++-----
x86-preempt-lazy.patch | 2 +-
2 files changed, 3 insertions(+), 6 deletions(-)
Den 01.11.2012 21:57, skrev Thomas Gleixner:
> Dear RT Folks,
>
> I'm pleased to announce the 3.6.5-rt14 release. 3.6.4-rt12 is an
> intermediate release with a few changes. 3.6.5-rt13 is an update to
> 3.6.5 and 3.6.5-rt14 has a fix for my stupidity to release from the
> wrong tree missing a fix for x86-32.
>
> Changes since 3.6.3-rt11:
>
> * Fix the fallout of preempt_lazy
>
> * Add preempt_lazy support for ARM and POWERPC
>
> * Fix a 32bit compile warning which got introduced with the
> random fixes.
>
> * Fix a missing lock conversion in the decive tree code
>
> The delta patch against 3.6.4-rt11 is can be found here:
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.4-rt11-rt12.patch.xz
>
> The RT patch against 3.6.5 can be found here:
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.5-rt14.patch.xz
>
> The split quilt queue is available at:
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.5-rt14.tar.xz
>
> Enjoy,
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Heya I see jitter is a focus on the RT patch.
I was wondering, what settings in features.h gives the least jitter? (I
am a real perfectionist)
Also what kind of threadpriorities gives the least jitter, particulary
with a focus on OpenGL? (Should some kernelthreads be reniced, for
instance softirqs etc)
And have you given consideration to the fact that most distros and OS
grow with some levels of bloat, and everyone can`t be an expert, so
maybe one shold consider a (scheduler) queue for "bloat", and one queue
for main app, so that even bloated distros can run with the jitteramount
of a highly specialized distro? (for instance
mainapp,service1,mainapp,service2,mainapp,service3), if bloat is on
queue 2. Or is thins kind of thinking already in batch, or idle?
--
Fred v?re med deg / Peace Be with You,
Ove Karlsen
http://www.paradoxuncreated.com
On Sat, 03 Nov 2012 20:04:58 +0100, Ove Karlsen said:
> And have you given consideration to the fact that most distros and OS
> grow with some levels of bloat, and everyone can`t be an expert, so
> maybe one shold consider a (scheduler) queue for "bloat", and one queue
> for main app, so that even bloated distros can run with the jitteramount
> of a highly specialized distro? (for instance
> mainapp,service1,mainapp,service2,mainapp,service3), if bloat is on
> queue 2. Or is thins kind of thinking already in batch, or idle?
So how does the kernel know which one is your "main app", and which one is
"bloat"? Hint - you can't base it on "the main app is the one using OpenGL" or
similar rule, as there may be multiple processes doing that, and you may
consider one of them to be bloat - and *I* might consider that one to be the
*important* one. Or even your definition may change around during the day - if
you're running Doom3, an OpenGL-capable window manager is probably "bloat", but
once you exit Doom3 and start working with multiple windows again, suddenly
you're going to want that window manager to be the "important" process again...