The normal and posix philosophers samples seemed to have
a number of redundant choices in prj.conf.
Let's reduce to the minimum required for the sample. The
CONFIG_DEBUG_THREAD_INFO option is part of the
documentation, so leave it as-is.
Signed-off-by: Christopher Friedt <cfriedt@meta.com>
For samples that set CONFIG_MP_NUM_CPUS=1, switch to using
CONFIG_MP_MAX_NUM_CPUS=1 instead as we work to phase out
CONFIG_MP_NUM_CPUS.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Enable thread awareness by default on philosophers sample. It shows
gdb debugging output using the feature as reference.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Disabling SMP mode for certain tests was a one-release thing, done to
avoid having to triage every test independently (MANY are not
SMP-safe), and with the knowledge that it was probably hiding bugs in
the kernel.
Turn it on pervasively. Tests are treated with a combination of
flagging specific cases as "1cpu" where we have short-running tests
that can be independently run in an otherwise SMP environment, and via
setting CONFIG_MP_NUM_CPUS=1 where that's not possible (which still
runs the full SMP kernel config, but with only one CPU available).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Tick rate is becoming a platform tunable in the tickless world. Some
apps were setting it due to requirements of drivers or subsystems (or
sometimes for reasons that don't make much sense), but the dependency
goes the other way around now: board/soc/arch level code is
responsible for setting tick rates that work with their devices.
A few tests still use hard-configured tick rates, as they have
baked-in assumptions (like e.g. "a tick will be longer than a
millisecond") that need to be addressed first.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A few more test cases that are measurably unreliable when run in SMP.
For the most part these work most of the time (though the semaphore
one was pretty borderline -- I measured about 25% failures), but are
measurably unstable against the backdrop of known qemu instability.
Something is clearly going on and we need to come back to these to fix
threadsafety issues.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These two tests ask for lots of priority levels, more than the 32
maximum allowed by SCHED_MULTIQ (which is by design: if you have
requirements like that DUMB or SCALABLE are better choices due to the
RAM overhead of MULTIQ), so the build will fail on boards that defined
MULTIQ as default.
Don't let the platform choose the scheduler backend, ask for SCALABLE
explicitly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
To have one project use more than 32 priorities. The preempt priorities
are also aligned so that they straddle two priority bitmaps.
Change-Id: I0f0862110d876e40fde45a0d105b769e8603d644
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Christopher Friedt