summaryrefslogtreecommitdiffstats
path: root/sys/arm/include/vmparam.h
diff options
context:
space:
mode:
authoralc <alc@FreeBSD.org>2009-04-04 23:12:14 +0000
committeralc <alc@FreeBSD.org>2009-04-04 23:12:14 +0000
commit85b0c58343338196160a3f3214cb1d10af9e5182 (patch)
tree096a8c4dae121c5d60e8cd039a81c8243558098f /sys/arm/include/vmparam.h
parent43f12bcbe6cd236c43a2796a77aca22e701d5f22 (diff)
downloadFreeBSD-src-85b0c58343338196160a3f3214cb1d10af9e5182.zip
FreeBSD-src-85b0c58343338196160a3f3214cb1d10af9e5182.tar.gz
Retire VM_PROT_READ_IS_EXEC. It was intended to be a micro-optimization,
but I see no benefit from it today. VM_PROT_READ_IS_EXEC was only intended for use on processors that do not distinguish between read and execute permission. On an mmap(2) or mprotect(2), it automatically added execute permission if the caller specified permissions included read permission. The hope was that this would reduce the number of vm map entries needed to implement an address space because there would be fewer neighboring vm map entries that differed only in the presence or absence of VM_PROT_EXECUTE. (See vm/vm_mmap.c revision 1.56.) Today, I don't see any real applications that benefit from VM_PROT_READ_IS_EXEC. In any case, vm map entries are now organized as a self-adjusting binary search tree instead of an ordered list. So, the need for coalescing vm map entries is not as great as it once was.
Diffstat (limited to 'sys/arm/include/vmparam.h')
-rw-r--r--sys/arm/include/vmparam.h2
1 files changed, 0 insertions, 2 deletions
diff --git a/sys/arm/include/vmparam.h b/sys/arm/include/vmparam.h
index bc82fd0..d54671d 100644
--- a/sys/arm/include/vmparam.h
+++ b/sys/arm/include/vmparam.h
@@ -141,8 +141,6 @@
#define SGROWSIZ (128*1024)
#define MAXSLP 20
-#define VM_PROT_READ_IS_EXEC
-
#ifdef ARM_USE_SMALL_ALLOC
#define UMA_MD_SMALL_ALLOC
#endif /* ARM_USE_SMALL_ALLOC */
OpenPOWER on IntegriCloud