mmap的对齐和粒度
我对 mmap 规范感到困惑。
设pa为mmap的返回地址（与规范相同）
pa = mmap(addr, len, prot, flags, fildes, off);
我认为函数调用成功后以下范围是有效的
[ pa, pa+len )
我的问题是以下范围是否仍然有效？
[ round_down(pa, 页大小) , round_up(pa+len, 页大小) )
简称[基数、基数+尺寸]
也就是说：
base总是在页面边界上对齐吗？size是否始终是 pagesize 的倍数（换句话说，粒度就是 pagesize）？
感谢您的帮助。
我认为这一段暗示了这一点：
off 参数被限制为根据 sysconf() 当传递 _SC_PAGESIZE 或 _SC_PAGE_SIZE 时。当指定 MAP_FIXED 时，应用程序应确保参数 addr 也满足这些约束。 该实现在整个页面上执行映射操作。因此，虽然参数 len 不需要满足大小或对齐约束，但实现应在任何映射操作中包括由范围 [pa,pa+len) 指定的任何部分页面。
但我不确定，而且我对 POSIX 没有太多经验。
- 请向我展示一些更明确和更多决定性证据
- ，或者向我展示至少一个支持 POSIX 并具有不同行为的系统，
再次感谢。
I am confused by the specification of mmap.
Let pa be the return address of mmap (the same as the specification)
pa = mmap(addr, len, prot, flags, fildes, off);
In my opinion after the function call succeed the following range is valid
[ pa, pa+len )
My question is whether the range of the following is still valid?
[ round_down(pa, pagesize) , round_up(pa+len, pagesize) )
[ base, base + size ] for short
That is to say:
- is the
basealways aligned on the page boundary? - is the
sizealways a multiple of pagesize (the granularity is pagesize in other words)?
Thanks for your help.
I think it is implied in this paragraph :
The off argument is constrained to be aligned and sized according to the value returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. When MAP_FIXED is specified, the application shall ensure that the argument addr also meets these constraints. The implementation performs mapping operations over whole pages. Thus, while the argument len need not meet a size or alignment constraint, the implementation shall include, in any mapping operation, any partial page specified by the range [pa,pa+len).
But I'm not sure and I do not have much experience on POSIX.
- Please show me some more explicit and more definitive evidence
- Or show me at least one system which supports POSIX and has different behavior
Thanks agian.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
考虑到 mmap 有许多不同的模式和配置，您的问题是相当开放的，但我将尝试涵盖最重要的点。
以将文件映射到内存的情况为例。文件中数据的开头始终以 mmap() 的返回地址为根。虽然操作系统实际上可能在页面边界创建了映射，但我不认为 POSIX 标准要求操作系统使该内存可写（例如，如果愿意，它可以在这些区域上强制出现段错误）。在映射文件的情况下，由文件支持的额外内存地址区域没有意义，这些区域未定义更有意义。
然而，对于 MMAP_ANONYMOUS，该内存可能是可写的——但是，再次强调，使用该内存是不明智的。
此外，当您使用 mmap() 时，您实际上使用的是 glibc 版本的 mmap()，并且它可能会以任何它认为合适的方式对内存进行切片和切块。最后，值得注意的是，在与 POSIX 兼容的 OSX 上，您提供的任何引用文本都不会出现在 mmap() 的手册页中。
Your question is fairly open-ended, considering that mmap has many different modes and configurations, but I'll try to cover the most important points.
Take the case in which you are mapping a file into memory. The beginning of the data in the file will always be rooted at the return address of mmap(). While the operating system may have actually created maps at page boundaries, I do not believe the POSIX standard requires the OS to make this memory writable (for example it could force segfaults on these regions if it wanted to). In the case of mapping files it doesn't make sense for this additional memory address regions to be backed by a file, it makes more sense for these regions to be undefined.
For MMAP_ANONYMOUS, however, the memory is likely writable--but, again, it would be unwise to use this memory.
Additionally, when you are using mmap() you are actually using glibc's version of mmap(), and it may slice and dice memory anyway it sees fit. Finally, it is worth noting that on OSX, which is POSIX compliant, none of the quoted text you presented appears in the man page for mmap().