On Wed, 26 Aug 2009, Peter Zijlstra wrote: > On Wed, 2009-08-26 at 11:41 -0400, Christoph Lameter wrote: > > On Wed, 26 Aug 2009, Peter Zijlstra wrote: > > > > > Why waste a whole cpu for something that could be done by part of one? > > > > Because of latency and performance requirements > > Latency is the only one, and yes people have been using hacks like this, > I've also earlier mentioned RTAI, RTLinux and L4-Linux which basically > do the same thing. > > The problem is, that its not linux, you cannot run something on a these > off-cores and use the same functionality as linux, if you could it'd not > be offline. Right. We discussed this. Why are you repeating the same old arguments? > Carving out cpus just doesn't work in the long run (see below for more), > it adds configuration burdens on people and it would duplicate > functionality (below), or it provides it in a (near) useless manner. Its pretty simple. Just isolate the cpu, forbid the OS to run anything on it. Allow a user space process to change its affinity to the isolated cpu. Should the process be so stupid as to ask the OS for services then just switch it back to a regular processor. Interaction is still possible via shared memory communication as well as memory mapped devices. > If you hack up special cases like this, then only your one use-case gets > better and the rest doesn't, or it might actually get worse, because it > got less attention. What special case? This is a generic mechanism. > > The kernel interactions can be done while running on another (not > > isolated) cpu. > > There needs to be some communication between the isolated and non > isolated part, otherwise what's the point. Even when you'd let it handle > say a network device as pure firewall, you'd need to configure the > thing, requiring interaction. Shared memory, memory mapped devices? > Interaction of any sorts gets serialization requirements, and from there > on things tend to grow. Yes and there are mechanism that provide the serialization without OS services. > > The functionality does not exist. This is about new features. > > It is not, he is proposing to use these cores for: > > - network stuff, we already have that > - raid5 stuff, we already have that > - other stuff we already have Right. I also want to use it for network stuff. Infiniband which support memory mapped registers and stuff. Its generic not special as you state. > Then there is the issue of what happens when a single core isn't > sufficient for the given task, then you'd need to split up, again > creating more interaction. Well yes you need to create synchronization methods that do not require OS interaction. > > > If you think the kernel is too fat and does superfluous things for your > > > needs, help trim it. > > > > Mind boogling nonsense. Please stop fantasizing and trolling. > > Oh, to lay down the crack-pipe and sod off. Dont have one here. Whats a sod off? -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
