☰

time 和 ulimit 指令使用的千位元組是 1000 (SI) 還是 1024（老式）位元組？

tag-icon • tag-icon ram memory-usage ulimit resource-limiting
time 和 ulimit 指令使用的千位元組是 1000 (SI) 還是 1024（老式）位元組？

從man time：

M      Maximum resident set size of the process during its lifetime, in Kilobytes.

從ulimit -a：

max memory size         (kbytes, -m) unlimited

但一個「千字節」可能表示 1000 或 1024 位元組。我猜這是一輪 1024，但我想確定一下。權威參考將不勝感激。

請隨意將我的問題改寫為：執行time並ulimit符合 IEC 建議，或在千字節含義中使用“kilobyte/kbyte”。

答案1

每man dir.1：

The SIZE argument is an integer and optional unit (example: 10K is 10*1024). Units are K,M,G,T,P,E,Z,Y (powers of 1024) or KB,MB,... (powers of 1000).

每info ls：

‘-h’
‘--human-readable’
Append a size letter to each size, such as ‘M’ for mebibytes. Powers of 1024 are used, not 1000; ‘M’ stands for 1,048,576 bytes. This option is equivalent to --block-size=human-readable. Use the --si option if you prefer powers of 1000.

的輸出ls在來源中進一步備份這裡和這裡。

看起來這個單字母就是 1024 的測量單位。他們兩個數位字元縮寫是 1000 SI 單位。

由於ulimitbash 內置，因此訪問其原始程式碼是最終的...原始碼。我經常很雙關語，但你可以看到這裡和這裡：

Values are in 1024-byte increments, except for -t, which is in seconds,
-p, which is in increments of 512 bytes, and -u, which is an unscaled
number of processes.

您的版本可能比 bash-5.2-rc3 更舊，這很好，自 4.0.38 發布以來，該專案的大小至少在過去十年中沒有改變。你可以看到這裡和這裡。

編輯：手冊頁units.7詳細解釋了這一點，但從單位保單。

答案2

不，千位元組是 1000。國際單位制因此前綴“kilo”指的是 1000 而不是 1024。

1024 是千位元組（氣羅雙沒有）

來自 ulimit -a：

最大記憶體大小（kbytes，-m）無限制

我認為這是一個錯誤。應明確註明公斤或基比；不是千字節

人時間：

M 進程在其生命週期內的最大駐留集合大小（以千位元組為單位）。

  • 極限值使用 KIBI 位元組

    limit.rlim_cur = newlimit * 512;
limit.rlim_max = newlimit * 512;

  • GNU時間如果您查看原始程式碼，則使用 KIBIbytes。說明書錯了。

    它用：

    tmp = pages / 1024;  /* Smaller first, */
size = tmp / 1024;    /* then smaller.  */

答案3

A千位元組是 1000 位元組（SI 前綴表示千）。 A千位元組是 1024 位元組（IEC 前綴表示千二進位）。

該約定自 1998 年以來一直使用，但我猜想這些前綴的用法並沒有像應有的那樣廣為人知。

這也是為什麼 1 TB（太字節）硬碟只有 0.91 TiB（太字節，由檔案系統報告）。

一個相關的問題是，當作者指出一個數字是在“千位元組”。由於這不是官方聲明，因此您不知道它們是指其中之一。

因為ulimit幫助頁面說：“值以 1024 位元組為增量”，我相信可以安全地假設它們實際上意味著千位元組當他們寫的時候千位元組。

另一方面，由於man time明確指出數值位於千位元組，我們必須假設作者知道 KB 是什麼，並且它們實際上意味著 1000 位元組。

但無論如何，為了 100% 確定作者沒有編寫任何明顯錯誤的內容，您應該檢查原始程式碼或諮詢程式的作者。

參考：

相關內容