sim: Consistently use ISO prefixes
authorAndreas Sandberg <andreas.sandberg@arm.com>
Thu, 21 Jan 2021 12:54:18 +0000 (12:54 +0000)
committerAndreas Sandberg <andreas.sandberg@arm.com>
Sun, 24 Jan 2021 18:45:01 +0000 (18:45 +0000)
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 <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39579
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
src/sim/Process.py
src/sim/syscall_emul.hh

index bdcb8262c464bc162f186d11007f40533853507a..767dbfa19981acac8de0e7d64fdd55e7644acb91 100644 (file)
@@ -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')
index 581e8dbcefb2e38279927280235a33e2ffcadfe2..d6afec88692f022a447ccc2573ca3c2d708ab3bf 100644 (file)
@@ -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);