> On Aug 22, 2022, at 10:42 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Mon, Aug 22, 2022 at 04:56:47PM +0000, Song Liu wrote: >> >> >>> On Aug 22, 2022, at 9:34 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: >>> >>> On Mon, Aug 22, 2022 at 03:46:38PM +0000, Song Liu wrote: >>>> Could you please share your feedback on this? >>> >>> I've looked at it all of 5 minutes, so perhaps I've missed something. >>> >>> However, I'm a little surprised you went with a second tree instead of >>> doing the top-down thing for data. The way you did it makes it hard to >>> have guard pages between text and data. >> >> I didn't realize the importance of the guard pages. But it is not too > > I'm not sure how important it is, just seems like a good idea to trap > anybody trying to cross that divide. Also, to me it seems like a good > idea to have a single large contiguous text region instead of splintered > 2M pages. A single large contiguous text region is great. However, it is not easy to keep it contiguous. For example, when we load a big module, and then unload it. It is not easy to recycle the space. Say we load module-x-v1, which is 4MB, and uses 2 huge pages. Then we load a small BPF program after it. The address space looks like: MODULE_VADDR to MODULE_VADDR + 4MB: module-x-v1 MODULE_VADDR + 4MB to MODULE_VADDR + 4MB + 4kB: bpf_prog_xxxx When we unload module-x-v1, there will be 4MB hole in the address space. If we then load module-x-v2, which is 4.1MB in size, we cannot reuse that hole, because the module is a little too big for the hole. AFAICT, to use the space efficiently, we will have to deal with splintered 2MB pages. Does this make sense? Thanks, Song > >> hard to do it with this approach. For each 2MB text page, we can reserve >> 4kB on the beginning and end of it. Would this work? > > Typically a guard page has different protections (as in none what so > ever) so that every access goes *splat*.
