Overall, I think that this is a good idea, but the implementation has the following problem. The allocation of one executable page will block the promotion of the surrounding pages to a superpage mapping. In short, the executable mappings should be segregated from the normal mappings. One possible approach is to create a separate arena for allocation of kernel virtual addresses that are executable And, that arena imports from the current arena at a superpage granularity.

In D15691#331801, @alc wrote:

Overall, I think that this is a good idea, but the implementation has the following problem. The allocation of one executable page will block the promotion of the surrounding pages to a superpage mapping.

This is easy enough to do. I wonder, however, if there is a concern about allocating a superpage of kernel address space for this, particularly on 32-bit systems. For example, if we used a different arena, a single use of M_EXEC memory on i386 would need to allocate 21 bits/2MB (PAE) or 22 bits/4MB (non-PAE) of kernel address space to that arena. I wonder if that would put unnecessary pressure on the available kernel address space?

Given the current use of these (just for the BPF just-in-time compiler), it may be that the performance penalty of non-superpage allocations is acceptable in this circumstance?

In D15691#332057, @jtl wrote:

In D15691#331801, @alc wrote:

Overall, I think that this is a good idea, but the implementation has the following problem. The allocation of one executable page will block the promotion of the surrounding pages to a superpage mapping.

This is easy enough to do. I wonder, however, if there is a concern about allocating a superpage of kernel address space for this, particularly on 32-bit systems. For example, if we used a different arena, a single use of M_EXEC memory on i386 would need to allocate 21 bits/2MB (PAE) or 22 bits/4MB (non-PAE) of kernel address space to that arena. I wonder if that would put unnecessary pressure on the available kernel address space?

Given the current use of these (just for the BPF just-in-time compiler), it may be that the performance penalty of non-superpage allocations is acceptable in this circumstance?

I understand the generic nature of your concern, for 32bit architectures. i386 in fact does not have a problem with KVA which would make it prohibitively costly to allocate 4M just for executable allocations. And I still did not merged PAE/non-PAE.

In D15691#331991, @jhb wrote:

Given how rarely executable memory is probably used (just bpf JIT currently), I'm not sure how big of an impact the fine-grained PG_NX permissions will be?

Here is my other concern with this change, and this affects all of the kmem arena. Since we are using vmem and not vm map entries to track what is allocated versus free, we have no record of which 4KB pages are executable and which ones are not at the machine-independent layer. This could have consequences.

Suppose that I attempt to optimize kmem_back_domain() by reducing the number of pmap_enter() calls that it performs by using pmap_enter(..., psind=1). Specifically, I remove the pmap_enter() call from the current allocation loop, and I introduce a second loop that first checks to see if the first allocated page (and any later page at the start of a superpage-sized region) comes from a full reservation. If it does, I do a single pmap_enter(..., psind=1) call for the entire superpage-sized region. Moreover, for kmem_back_domain(), there is no good reason why we are performing the pmap_enter() calls while the kernel object is locked.

However, if kmem_back_domain() can't be certain that there are no executable pages within the superpage-sized region, it can't use pmap_enter(..., psind=1). It has to always perform 4KB-sized pmap_enter() calls and rely on automatic promotion to do the right thing.

In D15691#332057, @jtl wrote:

In D15691#331801, @alc wrote:

Overall, I think that this is a good idea, but the implementation has the following problem. The allocation of one executable page will block the promotion of the surrounding pages to a superpage mapping.

This is easy enough to do. I wonder, however, if there is a concern about allocating a superpage of kernel address space for this, particularly on 32-bit systems. For example, if we used a different arena, a single use of M_EXEC memory on i386 would need to allocate 21 bits/2MB (PAE) or 22 bits/4MB (non-PAE) of kernel address space to that arena. I wonder if that would put unnecessary pressure on the available kernel address space?

There are other possible solutions besides creating an arena for the executable memory allocations. See for example kern/link_elf_obj.c. If we believe that the need for executable memory is so rare that it's not worth an arena, then I would argue that we should simply remove executable permissions from the pmap_enter() calls in vm_kern.c without introducing the M_EXEC flag and rewrite the memory allocation code in BPF to use other VM interfaces besides kmem_malloc().

Given the current use of these (just for the BPF just-in-time compiler), it may be that the performance penalty of non-superpage allocations is acceptable in this circumstance?

To be clear, I'm not really concerned that BPF doesn't benefit from superpage mappings, but rather that it does collateral damage to other nearby data that would have otherwise been accessed through superpage mappings.