From fd7bcb7ecd96274f86be0f948acb19f6fc4f66a5 Mon Sep 17 00:00:00 2001 From: Andreas Sandberg Date: Thu, 21 Jan 2021 12:54:18 +0000 Subject: [PATCH] sim: Consistently use ISO prefixes We currently use the traditional SI-like prefixes to represent binary multipliers in some contexts. This is ambiguous in many cases since they overload the meaning of the SI prefix. Here are some examples of commonly used in the industry: * Storage vendors define 1 MB as 10**6 bytes * Memory vendors define 1 MB as 2**20 bytes * Network equipment treats 1Mbit/s as 10**6 bits/s * Memory vendors define 1Mbit as 2**20 bits In practice, this means that a FLASH chip on a storage bus uses decimal prefixes, but that same flash chip on a memory bus uses binary prefixes. It would also be reasonable to assume that the contents of a 1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet link. That's however not the case due to different meanings of the prefix. The quantity 2MX is treated differently by gem5 depending on the unit X: * Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes. * Interconnect and NoC bandwidths (B/s) use binary prefixes. * Network bandwidths (bps) use decimal prefixes. * Memory sizes and storage sizes (B) use binary prefixes. Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes for binary multipliers for parameters and comments where appropriate. Change-Id: I797163c8690ae0092e00e371d75f5e7cebbcd1f5 Signed-off-by: Andreas Sandberg Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39579 Reviewed-by: Jason Lowe-Power Tested-by: kokoro --- src/sim/Process.py | 2 +- src/sim/syscall_emul.hh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/sim/Process.py b/src/sim/Process.py index bdcb8262c..767dbfa19 100644 --- a/src/sim/Process.py +++ b/src/sim/Process.py @@ -44,7 +44,7 @@ class Process(SimObject): useArchPT = Param.Bool('false', 'maintain an in-memory version of the page\ table in an architecture-specific format') kvmInSE = Param.Bool('false', 'initialize the process for KvmCPU in SE') - maxStackSize = Param.MemorySize('64MB', 'maximum size of the stack') + maxStackSize = Param.MemorySize('64MiB', 'maximum size of the stack') uid = Param.Int(100, 'user id') euid = Param.Int(100, 'effective user id') diff --git a/src/sim/syscall_emul.hh b/src/sim/syscall_emul.hh index 581e8dbce..d6afec886 100644 --- a/src/sim/syscall_emul.hh +++ b/src/sim/syscall_emul.hh @@ -1822,7 +1822,7 @@ getrlimitFunc(SyscallDesc *desc, ThreadContext *tc, const ByteOrder bo = OS::byteOrder; switch (resource) { case OS::TGT_RLIMIT_STACK: - // max stack size in bytes: make up a number (8MB for now) + // max stack size in bytes: make up a number (8MiB for now) rlp->rlim_cur = rlp->rlim_max = 8 * 1024 * 1024; rlp->rlim_cur = htog(rlp->rlim_cur, bo); rlp->rlim_max = htog(rlp->rlim_max, bo); @@ -1865,7 +1865,7 @@ prlimitFunc(SyscallDesc *desc, ThreadContext *tc, const ByteOrder bo = OS::byteOrder; switch (resource) { case OS::TGT_RLIMIT_STACK: - // max stack size in bytes: make up a number (8MB for now) + // max stack size in bytes: make up a number (8MiB for now) rlp->rlim_cur = rlp->rlim_max = 8 * 1024 * 1024; rlp->rlim_cur = htog(rlp->rlim_cur, bo); rlp->rlim_max = htog(rlp->rlim_max, bo); -- 2.30.2