Date: Fri, 21 Jan 2011 19:09:10 +0300 From: Sergey Kandaurov <pluknet@gmail.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: [rfc] allow to boot with >= 256GB physmem Message-ID: <AANLkTikt5=2L0rHyGbsjvG8eV6Ve4JkRM_pcyNiAsPu8@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--00163642748d7a0815049a5d78b6 Content-Type: text/plain; charset=ISO-8859-1 Hello. Some time ago I faced with a problem booting with 400GB physmem. The problem is that vm.max_proc_mmap type overflows with such high value, and that results in a broken mmap() syscall. The max_proc_mmap value is a signed int and roughly calculated at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: vm_kmem_size / sizeof(struct vm_map_entry) / 100. Although at the time it was introduced at svn r57263 the value was quite low (f.e. the related commit log stands: "The value defaults to around 9000 for a 128MB machine."), the problem is observed on amd64 where KVA space after r212784 is factually bound to the only physical memory size. With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) is 120, it's enough to have sligthly less than 256GB to be able to reproduce the problem. I rewrote vmmapentry_rsrc_init() to set large enough limit for max_proc_mmap just to protect from integer type overflow. As it's also possible to live tune this value, I also added a simple anti-shoot constraint to its sysctl handler. I'm not sure though if it's worth to commit the second part. As this patch may cause some bikeshedding, I'd like to hear your comments before I will commit it. http://plukky.net/~pluknet/patches/max_proc_mmap.diff -- wbr, pluknet --00163642748d7a0815049a5d78b6 Content-Type: application/octet-stream; name="max_proc_mmap.diff" Content-Disposition: attachment; filename="max_proc_mmap.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gj7a6ggp0 SW5kZXg6IHN5cy92bS92bV9tbWFwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX21tYXAuYwko cmV2aXNpb24gMjE3NTM1KQorKysgc3lzL3ZtL3ZtX21tYXAuYwkod29ya2luZyBjb3B5KQpAQCAt OTIsOCArOTIsMjkgQEAgc3RydWN0IHNicmtfYXJncyB7CiB9OwogI2VuZGlmCiAKKyNpZm5kZWYJ TUFYX1BST0NfTU1BUAorI2RlZmluZQlNQVhfUFJPQ19NTUFQIDEwMDAwMDAwCisjZW5kaWYKKwog c3RhdGljIGludCBtYXhfcHJvY19tbWFwOwotU1lTQ1RMX0lOVChfdm0sIE9JRF9BVVRPLCBtYXhf cHJvY19tbWFwLCBDVExGTEFHX1JXLCAmbWF4X3Byb2NfbW1hcCwgMCwKKworc3RhdGljIGludAor c3lzY3RsX21heF9wcm9jX21tYXAoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQgZXJyb3Is IG5ld192YWw7CisKKwluZXdfdmFsID0gbWF4X3Byb2NfbW1hcDsKKwllcnJvciA9IHN5c2N0bF9o YW5kbGVfaW50KG9pZHAsICZuZXdfdmFsLCAwLCByZXEpOworCWlmIChlcnJvciAhPSAwIHx8IHJl cS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCWlmIChuZXdfdmFsIDwgMCB8 fCBuZXdfdmFsID4gTUFYX1BST0NfTU1BUCkKKwkJZXJyb3IgPSBFSU5WQUw7CisJZWxzZQorCQlt YXhfcHJvY19tbWFwID0gbmV3X3ZhbDsKKwlyZXR1cm4gKGVycm9yKTsKK30KK1NZU0NUTF9QUk9D KF92bSwgT0lEX0FVVE8sIG1heF9wcm9jX21tYXAsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywK KyAgICAmbWF4X3Byb2NfbW1hcCwgMCwgc3lzY3RsX21heF9wcm9jX21tYXAsICJJIiwKICAgICAi TWF4aW11bSBudW1iZXIgb2YgbWVtb3J5LW1hcHBlZCBmaWxlcyBwZXIgcHJvY2VzcyIpOwogCiAv KgpAQCAtMTA5LDExICsxMzAsMTYgQEAgU1lTSU5JVCh2bW1lcnNyYywgU0lfU1VCX0tWTV9SU1JD LCBTSV9PUkRFUl9GSVJTVCwKICAgICBOVUxMKTsKIAogc3RhdGljIHZvaWQKLXZtbWFwZW50cnlf cnNyY19pbml0KGR1bW15KQotICAgICAgICB2b2lkICpkdW1teTsKK3ZtbWFwZW50cnlfcnNyY19p bml0KHZvaWQgKmR1bW15KQogewotICAgIG1heF9wcm9jX21tYXAgPSB2bV9rbWVtX3NpemUgLyBz aXplb2Yoc3RydWN0IHZtX21hcF9lbnRyeSk7Ci0gICAgbWF4X3Byb2NfbW1hcCAvPSAxMDA7CisJ dV9sb25nIHRtcF92YWw7CisKKwl0bXBfdmFsID0gdm1fa21lbV9zaXplIC8gc2l6ZW9mKHN0cnVj dCB2bV9tYXBfZW50cnkpIC8gMTAwOworCisJLyogQXZvaWQgaW50ZWdlciBvdmVyZmxvdy4gKi8K KwlpZiAodG1wX3ZhbCA+IE1BWF9QUk9DX01NQVApCisJCXRtcF92YWwgPSBNQVhfUFJPQ19NTUFQ OworCW1heF9wcm9jX21tYXAgPSAoaW50KXRtcF92YWw7CiB9CiAKIHN0YXRpYyBpbnQgdm1fbW1h cF92bm9kZShzdHJ1Y3QgdGhyZWFkICosIHZtX3NpemVfdCwgdm1fcHJvdF90LCB2bV9wcm90X3Qg KiwK --00163642748d7a0815049a5d78b6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikt5=2L0rHyGbsjvG8eV6Ve4JkRM_pcyNiAsPu8>