免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 6890 | 回复: 6
打印 上一主题 下一主题

mm_struct 中的 mm_count 和 mm_users ? [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2009-03-24 21:22 |只看该作者 |倒序浏览
mm_struct 中的 mm_count 和 mm_users 有什么不同? 分别用于什么场合? 为什么有这样的设计呢?
望高人指教呀~

论坛徽章:
0
2 [报告]
发表于 2009-03-24 21:37 |只看该作者
原帖由 kouu 于 2009-3-24 21:22 发表
mm_struct 中的 mm_count 和 mm_users 有什么不同? 分别用于什么场合? 为什么有这样的设计呢?
望高人指教呀~


ULK上面有解释的:
The mm_users field stores the number of lightweight processes that share the mm_struct data structure (see the section "The clone( ), fork( ), and vfork( ) System Calls" in Chapter 3). The mm_count field is the main usage counter of the memory descriptor; all "users" in mm_users count as one unit in mm_count. Every time the mm_count field is decreased, the kernel checks whether it becomes zero; if so, the memory descriptor is deallocated because it is no longer in use.

We'll try to explain the difference between the use of mm_users and mm_count with an example. Consider a memory descriptor shared by two lightweight processes. Normally, its mm_users field stores the value 2, while its mm_count field stores the value 1 (both owner processes count as one).

If the memory descriptor is temporarily lent to a kernel thread (see the next section), the kernel increases the mm_count field. In this way, even if both lightweight processes die and the mm_users field becomes zero, the memory descriptor is not released until the kernel thread finishes using it because the mm_count field remains greater than zero.

If the kernel wants to be sure that the memory descriptor is not released in the middle of a lengthy operation, it might increase the mm_users field instead of mm_count (this is what the try_to_unuse( ) function does; see the section "Activating and Deactivating a Swap Area" in Chapter 17). The final result is the same because the increment of mm_users ensures that mm_count does not become zero even if all lightweight processes that own the memory descriptor die.

The mm_alloc( ) function is invoked to get a new memory descriptor. Because these descriptors are stored in a slab allocator cache, mm_alloc( ) calls kmem_cache_alloc( ), initializes the new memory descriptor, and sets the mm_count and mm_users field to 1.

Conversely, the mmput( ) function decreases the mm_users field of a memory descriptor. If that field becomes 0, the function releases the Local Descriptor Table, the memory region descriptors (see later in this chapter), and the Page Tables referenced by the memory descriptor, and then invokes mmdrop( ). The latter function decreases mm_count and, if it becomes zero, releases the mm_struct data structure.

论坛徽章:
0
3 [报告]
发表于 2009-03-24 22:47 |只看该作者
多谢ls的回答。总算看明白了~
初始状态下,这两个值都是1。当 mm_users 减为 0 时,mm_count 会自减 1。也即是仅当 mm_users 减为 0 时,mm_count 才可能为 0。
mm_count 代表了对 mm 本身的引用,而 mm_users 代表对 mm 相关资源的引用,分了两个层次。
可能存在这样的情况,mm 已经没有人使用了(mm_users为0),所以其相关资源被释放掉(如vma);但是 mm 本身可能还在被人使用(比如被一个内核线程,它不会使用vma),所以 mm 本身还不能被释放;
这个理解应该没错吧?

论坛徽章:
16
2015亚冠之吉达阿赫利
日期:2015-08-17 11:21:462015年迎新春徽章
日期:2015-03-04 09:58:11酉鸡
日期:2014-12-07 09:06:19水瓶座
日期:2014-11-04 14:23:29天秤座
日期:2014-03-02 08:57:52双鱼座
日期:2014-02-22 13:07:56午马
日期:2014-02-14 11:08:18双鱼座
日期:2014-02-13 11:09:37卯兔
日期:2014-02-06 15:10:34子鼠
日期:2014-01-20 14:48:19戌狗
日期:2013-12-19 09:37:46射手座
日期:2013-12-19 09:33:47
4 [报告]
发表于 2011-08-17 09:54 |只看该作者
mm_count是主使用计数,mm_users是共享mm_struct的进程数,mm_users中的所有用户在mm_count中只作为一个单位

论坛徽章:
0
5 [报告]
发表于 2011-08-20 16:26 |只看该作者
mm_count类似于 以进程为单位。  mm_users类似于以线程为单位。

论坛徽章:
0
6 [报告]
发表于 2011-08-20 19:27 |只看该作者
恩。我当初对这个也有疑问。

Thanks above all.

论坛徽章:
16
2015亚冠之吉达阿赫利
日期:2015-08-17 11:21:462015年迎新春徽章
日期:2015-03-04 09:58:11酉鸡
日期:2014-12-07 09:06:19水瓶座
日期:2014-11-04 14:23:29天秤座
日期:2014-03-02 08:57:52双鱼座
日期:2014-02-22 13:07:56午马
日期:2014-02-14 11:08:18双鱼座
日期:2014-02-13 11:09:37卯兔
日期:2014-02-06 15:10:34子鼠
日期:2014-01-20 14:48:19戌狗
日期:2013-12-19 09:37:46射手座
日期:2013-12-19 09:33:47
7 [报告]
发表于 2011-08-31 16:53 |只看该作者
5楼的很透彻
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP