| 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
| ||
|
Message-ID: <1271942430.10448.196.camel@gandalf.stny.rr.com> Date: Thu, 22 Apr 2010 09:20:30 -0400 From: Steven Rostedt <rostedt@...dmis.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Primiano Tucci <p.tucci@...il.com>, linux-kernel@...r.kernel.org, tglx <tglx@...utronix.de> Subject: Re: Considerations on sched APIs under RT patch On Wed, 2010-04-21 at 22:58 +0200, Peter Zijlstra wrote: > > P.S. It actually does not happen in other RTOSes, e.g., VxWorks SMP > > I don't know any of those, but its impossible to migrate tasks from one > cpu to another without creating cross-cpu dependencies. > > Whether locks are preemptible or not doesn't make them any less > analyzable, if you use system-calls in your RT program, their > implementation needs to be considered It's been a while since I've used SMP VxWorks, but back then what it did was to copy an image for ever CPU separately. It was not really SMP but instead a separate OS for each CPU. Things may have changed since then (it was around 2002 when I saw this). There's projects to do the same for Linux, and I feel it may give you the most control of the system. But the hardware is still shared, so the contention does not go away, it just gets moved to the hardware resources. -- Steve -- 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