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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ