On 11/2/2012 6:11 AM, Michael Haberler wrote: > I wonder if the current scheme can be improved under the following angles: > > - the current RTAI RTAPI uses only _one_ isolated CPU for 'RT Threads' (i.e. > all of them) even if the underlying hardware has more than two cores. > I assume in the case where there are several RTAPI threads on a single > isolated CPU there would be CPU and cache contention _among_ those RT threads > for that CPU > I would guess it might make sense to allow binding of threads to separate > CPU's (note plural) if the hardware supports this, in the hope the reduced > contention might improve latency > > - massively multicore CPU's are around the corner, and linuxcnc has no > effective method to make use of more than one for threads. > > - the current 'isolcpus=1' boot argument essentially takes the 'RT core' > offline for good - why? the cpusets facility could do that dynamically > without reboot, and handly any number of cores? > > There is some cpusets code in the RT_PREEMPT work by Michael Büsch which > could be generalized; which is needed anyway because the CPU core-to-thread > binding is an issue with userland threads too. > > Any obvious errors in the above line of thought? > > > A related question: > > what is the rationale to have _motion_ start threads, if we have a threads > module to start with? this looks entirely unsystematic to me - I dont > understand what's so specific about motion that it just has to do this. Any > other explanation than 'history'? > > > - Michael > >
Makes good sense to me. I've had similar thoughts about this quad-core Athlon of mine but it wasn't until Charles and I had several exchanges about trying to improve the latency of my PREEMPT_RT tests that I even heard of the cpusets facility. As for motion, perhaps we're just seeing the effect of evolution. Something that worked "good enough" never got changed. Regards, Kent ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
