怎么区分一个物理页面属于内核还是用户空间

amarant

我觉得lz这个问题挺好的，我说说我的理解，不对之处大家多多指教，为了少打几个字，下面用用户指示用户空间，内核指示内核空间
一个物理页可以被内核使用，也可以被用户使用。但是它从伙伴系统分配出来只有一次
如果被内核分配出来后，那么用户就不可能再拥有这个页了。（用户通过系统调用分配页，如果一个页已经不再伙伴系统中，那么就不会给用户了）。但上述逻辑没有考虑到mmap系统调用（这个系统调用太imba了）。用户也可以去直接操作物理地址（这里是不是绕过了伙伴系统呢？）
小结：用户所占用的物理页是有反向映射的，是通过lru管理的。但是内核占用的页是没有在lru中的。所以大致可以通过struct page中的mapping字段判断

junnyg

回复 11# amarant
是指直接对“/dev/mem” mmap 吗?buddy应该不感知吧


   

unbutun

                        查tlb

amarant

回复 12# junnyg


    是的，对/dev/mem mmap后，几乎和内核的权限一样大了

embeddedlwp

回复 11# amarant


用户空间使用的hugetlbfs page不在lru上的, 用户进程页表占用的页也不在。

/dev/mem只是让用户访问mmio的内存，内核使用的内存从RAM分配，不会从这里分配，而且/dev/mem的内存也不归buddy管理的。

embeddedlwp

回复 9# f22jay


the fucking source codes.


   

junnyg

回复 15# embeddedlwp
hugetlb page使用自己的freelist管理，不归回收算法管，不过THP之后好像支持了大页换出的功能

用户程序占用的页表资源属于内核态使用的资源，建立修改清除都是内核来做的；

/dev/mem不能访问系统的全内存吗？


   

embeddedlwp

回复 17# junnyg

》hugetlb page使用自己的freelist管理，不归回收算法管，不过THP之后好像支持了大页换出的功能

Agreed.

》用户程序占用的页表资源属于内核态使用的资源，建立修改清除都是内核来做的；

page table属于user process的，看oom_badness中对user process所用内存的计算： get_mm_rss(p->mm) + p->mm->nr_ptes + get_mm_counter(p->mm, MM_SWAPENTS); (v3.9-rc7)

》/dev/mem不能访问系统的全内存吗？

系统的内存分RAM和mmio两类，/dev/mem专门用于user process访问mmio的。


   

amarant

回复 15# embeddedlwp


   你好，谢谢指出。关于mmap，我花了一点时间测试。用的是git上最新的内核，arch采用的是mips。结果跟你说的不太一样。测试过程如下
代码：

1. #include <stdio.h>
   
2. #include <unistd.h>
   
3. #include<sys/mman.h>
   
4. #include<sys/types.h>
   
5. #include<sys/stat.h>
   
6. #include<fcntl.h>
   
7. 
   
8. int main(int argc, char *argv[])
   
9. {
   
10.         int fd, i;
    
11.         long* map_base, *addr;
    
12.         off_t offset = 0;
    
13. 
    
14.         printf("start\n");
    
15.         fd = open("/dev/mem", O_RDWR|O_SYNC);
    
16.         if ( fd == -1 ) {
    
17.                 printf("open failed\n");
    
18.                 return -1;
    
19.         }
    
20. 
    
21.         if (argv[1])
    
22.                 offset = atol(argv[1]);
    
23.         map_base = mmap(0, 0x10*sizeof(long), PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
    
24.         if ( (long)map_base < 0) {
    
25.                 printf("mmap failed\n");
    
26.                 return -1;
    
27.         }
    
28.         addr = map_base;
    
29.         printf("phys: %p -> virt: %p\n", (void*)offset, addr);
    
30. 
    
31.         for (i = 0; i < 0x10; ++i){
    
32.                 printf("address: 0x%p   content 0x%lx\n", addr, *addr);
    
33.                 addr ++;
    
34.         }
    
35. 
    
36.         munmap(map_base, 0x10*sizeof(long));
    
37.         close(fd);
    
38. 
    
39.         return (1);
    
40. }
    

复制代码

执行结果：

1. / # /a.out 2097152
   
2. start
   
3. phys: 0x200000 -> virt: 0x773c9000
   
4. address: 0x0x773c9000   content 0x0
   
5. address: 0x0x773c9004   content 0xde220000
   
6. address: 0x0x773c9008   content 0x212fa
   
7. address: 0x0x773c900c   content 0x30420001
   
8. address: 0x0x773c9010   content 0x2c420001
   
9. address: 0x0x773c9014   content 0x20336
   
10. address: 0x0x773c9018   content 0xc0b465a
    
11. address: 0x0x773c901c   content 0xde320030
    
12. address: 0x0x773c9020   content 0x24030010
    
13. address: 0x0x773c9024   content 0xd2440000
    
14. address: 0x0x773c9028   content 0x832825
    
15. address: 0x0x773c902c   content 0xf2450000
    
16. address: 0x0x773c9030   content 0x10a0fffc
    
17. address: 0x0x773c9034   content 0x0
    
18. address: 0x0x773c9038   content 0x30840010
    
19. address: 0x0x773c903c   content 0x14800060
    
20. / # QEMU 1.4.50 monitor - type 'help' for more information
    
21. (qemu) xp/16 0x200000
    
22. 0000000000200000: 0x00000000 0xde220000 0x000212fa 0x30420001
    
23. 0000000000200010: 0x2c420001 0x00020336 0x0c0b465a 0xde320030
    
24. 0000000000200020: 0x24030010 0xd2440000 0x00832825 0xf2450000
    
25. 0000000000200030: 0x10a0fffc 0x00000000 0x30840010 0x14800060
    
26. (qemu)
    

复制代码

embeddedlwp

回复 19# amarant


这个offset不是物理地址，而是在文件中的偏移，能在x86上运行吗，mips不懂啊。