linux-kernel - [Announce] 2.6.29-rc78rt1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0903200014320.29264@localhost.localdomain>
Date:	Fri, 20 Mar 2009 01:31:41 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	LKML <linux-kernel@...r.kernel.org>
cc:	rt-users <linux-rt-users@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Carsten Emde <ce@...g.ch>,
	Clark Williams <williams@...hat.com>,
	Frank Rowand <frank.rowand@...sony.com>
Subject: [Announce] 2.6.29-rc78rt1

We are pleased to announce the next update to our new preempt-rt
series.

   - port forward to 2.6.29-rc8
   - disable -rt conflicting config options
   - hotplug cpu fixes (peterz)
   - slab/pagealloc lock breaks (peterz / tglx) 
   - sigqueue caching for -rt tasks
   - posixtimer thread avoid useless wakeups
   - various build fixes (mingo, frank ....)
   - lots of tracer updates from -tip (check the tip git logs)

The outstanding improvement is the slab/pagealloc change which breaks
and splits locking and brought down worst case latencies in
problematic use cases from >500us to <100us.

As a side note:

   There seems to be a wide spread underestimation of the problem spots
   exposed by preempt-rt. The usual shrug off answer is:

	"I don't care about -rt. Come back if you can expose the same
	problem in the mainline kernel."

   This is a fundamentally wrong answer.

   	preempt-rt mostly exposes existing latency spots and magnifies
   	them

	Reducing latencies in -rt by a factor 5 will be not that
	prominent in a non-rt setup, but the problematic code area
	will still produce measureable latency problems.

   I'm well aware of the tradeoff between determinitic behaviour and
   throughput, but problematic spots (e.g. lock contentions) hurt
   both.

   So can we please put down the stupid "I don't care about -rt"
   attitudes and accept that we have to think about the mutual
   benefits of deterministic and throughput aspects without hurting
   each other ?

Download locations:

    http://rt.et.redhat.com/download/
    http://www.kernel.org/pub/linux/kernel/projects/rt/

Information on the RT patch can be found at:

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

to build the 2.6.29-rc8-rt1 tree, the following patches should be
applied:

  http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
  http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt1.bz2

The broken out patches are also available at the same download
locations.

Enjoy !

       tglx

P.S.: ARM/PowerPC support is in the pipeline and will be available
      with -rt2 (hopefully :)

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