对于 中的给定进程/proc/<pid>/smaps，对于给定的映射条目是：
是Shared_Clean+Shared_Dirty是与其他进程共享的存储器的量？所以它就像共享RSS？
同样是Private_Clean+仅可用于一个进程Private_Dirty的内存量？所以它就像私人RSS？
PSS 值是否 = PrivateRSS +（SharedRSS / 共享它的进程数）？
阅读此链接后还有一些问题：LWN
现在让我们从整体上讨论这个过程，我们正在查看其 smaps 条目。
我注意到，如果我为流程的每个 smaps 条目执行Shared_Clean+ Shared_Dirty+ Private_Clean+ Private_Dirty，我会得到流程的 RSS 报告ps，这非常酷。例如
ps -p $$ -o pid,rss
将为我提供与/proc/$$/smaps中每个Shared_Clean, Shared_Dirty, Private_Clean,Private_Dirty条目的总和（大约）相同的 rss 值。
但是整个过程的PSS呢？那么，从上面的示例中，我如何获得 $$ 的 PSS？我可以为每个 smaps 映射添加 PSS 条目并以 $$ 到达 PSS 吗？
那么整个过程中的USS …
我有
link -> file
我愿意
find -L . -name 'link'
并得到
./link
这是为什么？
man find 说：
-L ：遵循符号链接。当 find 检查或打印有关文件的信息时，所使用的信息应取自链接指向的文件的属性，而不是来自链接本身（除非它是损坏的符号链接或 find 无法检查文件）链接指向的）。
我有一个嵌入式设备。它基于 ARM，使用 Linux 2.6.31 和 256 MB RAM。
我想就什么是测试设备 RAM 数据损坏的最有效方法获得一些想法/提示。有人可以建议测试/软件吗？
笔记：
我现在有 memtester。我是在 Ulrich Dangel（下图）的建议下得到的。
我现在也mtest从uboot设置了。
我可以使用任何其他测试/方法吗？
当我统计一个目录时，我得到一个列表，告诉我有 5 个指向该目录的链接。
stat dir
我的问题是如何获取所有这 5 个链接的信息（名称和位置）？
我在 uboot 中，想知道如何知道 uboot 正在使用什么 RAM 地址范围。
uboot 需要内存才能运行，因此它可能正在使用一些 RAM。我想避免修改这些 RAM 地址。
我如何知道 uboot 加载了哪个内存区域？
我想知道 ps 输出中的 SZ、RSS 和 VSZ 输出之间有什么数学联系，例如
ps -p 2363 -o sz,rss,vsz
如果我忘记了用户名和密码，如何登录我的 Linux 笔记本电脑？
在我的 Linux 主机上，Ctrl+C似乎不起作用，我不知道如何继续使其工作。我将 Ubuntu 10.04 与 bash 4.1.5(1) 一起使用，并在 Gnome 终端中工作。
当我在此脚本运行时按下Ctrl+C时，它并没有导致它退出。
#!/bin/bash
for i in `seq 500`
do
ps -e > /dev/null
echo $i
done
我正在将一个 550MB 的文件读入 /dev/null 并且我得到
dd: writing '/dev/null': No space left on device
我很惊讶。我认为 /dev/null 是一个黑洞，您可以在其中随意发送（因为它是虚拟文件系统）。
是的，当我收到此错误时，我的磁盘几乎已满。除了从磁盘中删除内容之外，我还能做什么？
ls -l /dev/null
-rw-r--r-- 1 root root 0 July 7 21:58 /dev/null
代替
crw-rw-rw- 1 root root 1, 3 July 7 02:58 /dev/null
我正在使用的命令：
time sh -c "dd if=$filename of=/dev/null"
当我看到有足够的内存可用时，我无法理解为什么内核会发出这个 oom 杀手：
另外为什么分配了这么多内核缓存页面？我看后说有足够的可用内存
普通的
DMA
普通自由行
这是一个基于 NAND 闪存的嵌入式设备，具有 256 MB RAM
内核：2.6.31
myshellscript invoked oom-killer: gfp_mask=0xd0, order=2, oomkilladj=0
Backtrace:
[<c0106494>] (dump_backtrace+0x0/0x110) from [<c03641a0>] (dump_stack+0x18/0x1c)
r6:000000d0 r5:c9040c60 r4:00000002 r3:c0448690
[<c0364188>] (dump_stack+0x0/0x1c) from [<c015a314>] (oom_kill_process.clone.11+0x60/0x1b4)
[<c015a2b4>] (oom_kill_process.clone.11+0x0/0x1b4) from [<c015a738>] (__out_of_memory+0x154/0x178)
r8:c21e86e0 r7:001fb000 r6:00000002 r5:000000d0 r4:c9b6e000
[<c015a5e4>] (__out_of_memory+0x0/0x178) from [<c015a980>] (out_of_memory+0x68/0xa0)
[<c015a918>] (out_of_memory+0x0/0xa0) from [<c015d230>] (__alloc_pages_nodemask+0x42c/0x520)
r5:00000002 r4:000000d0
[<c015ce04>] (__alloc_pages_nodemask+0x0/0x520) from [<c015d388>] (__get_free_pages+0x18/0x44)
[<c015d370>] (__get_free_pages+0x0/0x44) from [<c0109418>] (get_pgd_slow+0x1c/0xe0)
[<c01093fc>] (get_pgd_slow+0x0/0xe0) from [<c0129ab0>] (mm_init.clone.43+0xb0/0xf0)
r7:c90858c0 r6:00000000 r5:c90858c0 r4:ce1a6680
[<c0129a00>] (mm_init.clone.43+0x0/0xf0) from [<c0129c40>] …