patacongo commented on issue #37: examples: hello: Show CPU index when running in SMP mode URL: https://github.com/apache/incubator-nuttx-apps/pull/37#issuecomment-580817657 "... but the better approach is expose this information through the offiical API, something lke sched_getcpu: http://man7.org/linux/man-pages/man3/sched_getcpu.3.html"; I am not sure exactly how official that is. It is not a Linux API, git is a non-standard GLIBC interface that requires __GNU_SOURCE be defined to be available. That is far from standard; it is not even standard for GLIBC. sched_getcpu() is really just a wrapper around the Linux system call getcpu(): http://man7.org/linux/man-pages/man2/getcpu.2.html It is interested to note: "The information placed in cpu is guaranteed to be current only at the time of the call..., the kernel might change the CPU at any time. (_Normally this does not happen because the scheduler tries to minimize movements between CPUs to keep caches hot, but it is possible_.) The caller must allow for the possibility that the information returned ... is no longer current by the time the call returns. But in a realtime system, we cannot behave that way. realtime behavior is achieved by always being responsive and not by deferring CPU context switches to get better performance and throughput. That is why NuttX will never be a good desktop OS and Linux, without extensions, will never be a good realtime OS: Baseline Linux focus on throughput, and RTOS focuses on responsiveness. The result is that CPU switches will occur much more unpredictably and at a much higher rate than would be with Linux. This will give us realtime response, but the penalty that we pay is loss of throughput, primarily because of poorer use of data caches -- if available. And it also means that any user-space API to get the current CPU will be essentially useless on a very busy system because it will very often not report the correct CPU that the thread is running on. How often? For low priority tasks in such a busy system, very often.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
