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