Hi John,
John Kacur <jkacur@xxxxxxxxxx> writes:
> On Wed, 1 Sep 2021, Punit Agrawal wrote:
>
>> From: Punit Agrawal <punit1.agrawal@xxxxxxxxxxxxx>
>>
>> The hackbench workload refues to run on RockPro64, a hexacore 64bit
>> Arm board with 4GB memory, complaining about insufficient memory
>> per-core.
>>
>> On further investigation, it turns out that workload is using an
>> arbitrary limit of 0.75 GB/core but will quite happily run on much
>> lower lower memory systems.
>>
>> Instead of preventing execution, convert the info message to a warning
>> when the memory is lower than expected but continue execution. This
>> should enable the workload to be used on a wider range of systems.
>>
>> Signed-off-by: Punit Agrawal <punit1.agrawal@xxxxxxxxxxxxx>
>> ---
>> rteval/modules/loads/hackbench.py | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/rteval/modules/loads/hackbench.py b/rteval/modules/loads/hackbench.py
>> index 3b692070e9d9..ab028c495d8b 100644
>> --- a/rteval/modules/loads/hackbench.py
>> +++ b/rteval/modules/loads/hackbench.py
>> @@ -55,9 +55,8 @@ class Hackbench(CommandLineLoad):
>> if ratio >= 0.75:
>> mult = float(self._cfg.setdefault('jobspercore', 2))
>> else:
>> - self._log(Log.INFO, "Low memory system (%f GB/core)! Not running" % ratio)
>> + self._log(Log.WARN, "Low memory system (%f GB/core)!" % ratio)
>> mult = 0
>> - self._donotrun = True
>>
>> sysTop = SysTopology()
>> # get the number of nodes
>> --
>> 2.32.0
>>
>>
>
> I'm not sure that I can accept this. The number isn't entirely arbitrary,
> it's based on verifying machines as realtime capable for customers, in
> which case I'd rather it fails early.
I think there's a misunderstanding. The above check only prevents the
hackbench workload from running - which takes ~2-3MB in the default
configuration on the board I tested. rteval (along with cyclictest,
kcompile and other workloads) executes without any issues.
In terms of memory requirements for real time systems, I am not sure
there is a single number that is valid across all applications or
systems. Any such requirement only manages to alienate certain class of
rteval users. I thought a warning was a good compromise.
I am hoping you will reconsider the need to introduce a user option for
this case.
> Maybe there is some other way to indicate that the user is okay with
> lower memory system, such as passing an --embedded flag or something
> of that nature?
If the above doesn't convince you, I will look to adding an option. How
about calling the option "--low-memory-system" to clearly state what it
enables. "Embedded" is not well-defined and hard to guess what it
relates to.
