xiaoxiang781216 commented on code in PR #12020:
URL: https://github.com/apache/nuttx/pull/12020#discussion_r1545732546
##########
sched/timer/timer_initialize.c:
##########
@@ -37,6 +37,8 @@
#ifndef CONFIG_DISABLE_POSIX_TIMERS
+#define g_prealloctimers() this_cpu_var(g_prealloctimers)
Review Comment:
function name shouldn't start with g_ prefix
##########
sched/Kconfig:
##########
@@ -357,17 +357,6 @@ config SMP
Enables support for Symmetric Multi-Processing (SMP) on a
multi-CPU
platform.
- N.B. SMP mode requires the use of ARCH_INTERRUPTSTACK:
Review Comment:
why remove
##########
sched/Kconfig:
##########
@@ -398,6 +387,64 @@ config SMP_CALL
endif # SMP
+config BMP
Review Comment:
SMP and BMP should mutual exclusion
##########
sched/signal/sig_action.c:
##########
@@ -40,6 +40,8 @@
#include "group/group.h"
#include "signal/signal.h"
+#define g_sigaction_spin() this_cpu_var(g_sigaction_spin)
Review Comment:
why not remove () from the macro
##########
include/nuttx/compiler.h:
##########
@@ -1099,6 +1099,26 @@
# undef CONFIG_FS_LARGEFILE
#endif
+/* These are macros to access the current CPU and the current task on a CPU.
+ * These macros are intended to support a future SMP implementation.
+ */
+
+#ifndef __ASSEMBLY__
+extern unsigned long __cpu_data_size;
Review Comment:
g_cpu_data_size
##########
include/nuttx/compiler.h:
##########
@@ -1099,6 +1099,26 @@
# undef CONFIG_FS_LARGEFILE
#endif
+/* These are macros to access the current CPU and the current task on a CPU.
Review Comment:
why move sched specific macro to compiler.h
##########
sched/Kconfig:
##########
@@ -398,6 +387,64 @@ config SMP_CALL
endif # SMP
+config BMP
+ bool "Bound Multi-Processing (BMP)"
+ default n
+ depends on ARCH_HAVE_MULTICPU
+ depends on ARCH_HAVE_TESTSET
+ depends on ARCH_INTERRUPTSTACK != 0
+ select SPINLOCK
+ ---help---
+ Enables support for Bound Multi-Processing (BMP) on a multi-CPU
+ platform. Bound multiprocessing provides the scheduling control
+ of an asymmetric multiprocessing model, while preserving the
+ hardware abstraction and management of symmetric multiprocessing.
+
+ BMP is similar to SMP, but you can specify which processors a thread
+ can run on. You can use both SMP and BMP on the same system, allowing
+ some threads to migrate from one processor to another, while other
+ threads are restricted to one or more processors.
+
+ As with SMP, a single copy of the OS maintains an overall view of all
+ system resources, allowing them to be dynamically allocated and shared
+ among applications. But, during application initialization, a setting
+ determined by the system designer forces all of an application's
threads
+ to execute only on a specified CPU.
+
+ Compared to full, floating SMP operation, this approach offers several
+ advantages:
+
+ 1. It eliminates the cache thrashing that can reduce performance in
an SMP
+ system by allowing applications that share the same data set to run
+ exclusively on the same CPU.
+ 2. It offers simpler application debugging than SMP since all
execution
+ threads within an application run on a single CPU.
+ 3. It helps legacy applications that use poor techniques for
synchronizing
+ shared data to run correctly, again by letting them run on a single
CPU.
+
+if BMP
+
+config BMP_NCPUS
Review Comment:
it's better to reuse SMP_NCPUS and SMP_CALL, but make BMP is a child option
of SMP
--
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.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
