Tom Horsley writes:
On Tue, 13 Sep 2016 19:10:13 -0400 Tom Horsley wrote: > I'm not exactly sure about any of that though. If I > look at some maps files, there always seems to be > one of these ---p regions somewhere in the middle > of each shared library. I found this:http://unix.stackexchange.com/questions/226283/shared-library-mappings-in- proc-pid-mapsIt says the private only pages are gaps between readonly and readwrite to get aligned to a page boundary.
The gaps are more than enough for a 4kb page alignment.I augmented the output of /proc/pid/maps to show the length of each hexadecimal region, and nl-ed the output.
The first three mappings are /usr/sbin/named, then the next 19 mappings with kernel 4.6.7 are:
4 560c39d87000-560c39d8b000 16.00 Kb rw-p 00000000 00:00 0
5 560c3a3ae000-560c3a3cf000 132.00 Kb rw-p 00000000 00:00
0
[heap]
6 560c3a3cf000-560c3a43b000 432.00 Kb rw-p 00000000 00:00
0
[heap]
7 7fa2a0000000-7fa2a0085000 532.00 Kb rw-p 00000000 00:00 0
8 7fa2a0085000-7fa2a4000000 65004.00 Kb ---p 00000000 00:00 0
9 7fa2a8000000-7fa2a806f000 444.00 Kb rw-p 00000000 00:00 0
10 7fa2a806f000-7fa2ac000000 65092.00 Kb ---p 00000000 00:00 0
11 7fa2ac000000-7fa2ac05e000 376.00 Kb rw-p 00000000 00:00 0
12 7fa2ac05e000-7fa2b0000000 65160.00 Kb ---p 00000000 00:00 0
13 7fa2b0000000-7fa2b3085000 49684.00 Kb rw-p 00000000 00:00 0
14 7fa2b3085000-7fa2b4000000 15852.00 Kb ---p 00000000 00:00 0
15 7fa2b5bc7000-7fa2b7d4b000 34320.00 Kb rw-p 00000000 00:00 0
16 7fa2b7d4b000-7fa2b7d4c000 4.00 Kb ---p 00000000 00:00 0
17 7fa2b7d4c000-7fa2b854c000 8192.00 Kb rw-p 00000000 00:00 0
18 7fa2b854c000-7fa2b854d000 4.00 Kb ---p 00000000 00:00 0
19 7fa2b854d000-7fa2b8d4d000 8192.00 Kb rw-p 00000000 00:00 0
20 7fa2b8d4d000-7fa2b8d4e000 4.00 Kb ---p 00000000 00:00 0
21 7fa2b8d4e000-7fa2b954e000 8192.00 Kb rw-p 00000000 00:00 0
22 7fa2b954e000-7fa2b954f000 4.00 Kb ---p 00000000 00:00 0
And with kernel 4.7.2, the same 19 mappings are:
4 56099c4a9000-56099c4ad000 16.00 Kb rw-p 00000000 00:00 0
5 56099e11c000-56099e13d000 132.00 Kb rw-p 00000000 00:00
0 [heap]
6 56099e13d000-56099e1a9000 432.00 Kb rw-p 00000000 00:00
0 [heap]
7 7f04dc000000-7f04dc021000 132.00 Kb rw-p 00000000 00:00 0
8 7f04dc021000-7f04e0000000 65404.00 Kb ---p 00000000 00:00 0
9 7f04e379f000-7f04e4000000 8580.00 Kb rw-p 00000000 00:00 0
10 7f04e4000000-7f04e4032000 200.00 Kb rw-p 00000000 00:00 0
11 7f04e4032000-7f04e8000000 65336.00 Kb ---p 00000000 00:00 0
12 7f04e8000000-7f04e8029000 164.00 Kb rw-p 00000000 00:00 0
13 7f04e8029000-7f04ec000000 65372.00 Kb ---p 00000000 00:00 0
14 7f04ec000000-7f04ec02d000 180.00 Kb rw-p 00000000 00:00 0
15 7f04ec02d000-7f04f0000000 65356.00 Kb ---p 00000000 00:00 0
16 7f04f0000000-7f04f002e000 184.00 Kb rw-p 00000000 00:00 0
17 7f04f002e000-7f04f4000000 65352.00 Kb ---p 00000000 00:00 0
18 7f04f4000000-7f04f402d000 180.00 Kb rw-p 00000000 00:00 0
19 7f04f402d000-7f04f8000000 65356.00 Kb ---p 00000000 00:00 0
20 7f04f8000000-7f04f8038000 224.00 Kb rw-p 00000000 00:00 0
21 7f04f8038000-7f04fc000000 65312.00 Kb ---p 00000000 00:00 0
22 7f04fc000000-7f04ff206000 51224.00 Kb rw-p 00000000 00:00 0
The first half of the mappings are roughly comparable. Then, with kernel
4.7.2, the remaining mappings remain more or less the same. In 4.6.7, the
remaining mappings are much smaller.
Did the new kernel change the default page size so the gaps need to be bigger now? (You'd think most of the universe would panic if the page size changed from 4K though :-).
Note how under 4.7.2, the read/write mapping and the immediately following buffer mapping tend to be 65536Kb in total size.
In 4.7.2, the first couple of mappings do seem to align to a 64kb boundary, but not all of them, the last half of the shown mappings do not align to 64kb boundaries, each.
The question now becomes how does this translate to bind's "datasize" config option work.
I originally had "datasize 20M" before 4.7.2. I upped it to "datasize 64M". named-chroot still failed to start.I upped it to "datasize 256M". named-chroot started. I looked into /proc/pid/limits, and I saw that "Max data size" was now set. It was set to 256 megabytes.
From that, I conclude that bind does not manage "datasize n" internally, it
just uses it to set its own ulimit.So, it seems that bind runs comfortably with a 20mb data ulimit in <4.7.2 can't even fit within a 64M data ulimit in 4.7.2.
How is this reconciled with the changes in the process mappings? Does ulimit just set the upper range of the data segment numerically, in which case the larger gaps would certainly eat into that rather quickly? But other evidence suggests that this is not the case:
The actual row in /proc/pid/limits is: Max data size 268435456 268435456 bytes Counting on my fingers, that's 256 megabytes.Each pair of mappings, above, adds up to 65536kb, which is 64 megabytes. Unless I'm a bit slow mentally, today; but that's what it looks like to me, so the first four of those mappings would've blown through that limit, and there are quite a few more of those mappings. That would suggest that ulimit does not just set a raw cutoff for virtual memory addresses (which jives with what I read in mmap(), et. al.)
So, what the heck is going on.
Attachment:
pgpt9sH_8QDmb.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
