> 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 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? There are a couple benefits from a second tree: 1. It allows text allocations to go below PAGE_SIZE granularity, while data allocations would still use PAGE_SIZE granularity, which is the same as current code. 2. Text allocate requires mapping one vm_struct to many vmap_area. Putting text allocations in a separate tree make it easier to handle this. (Well, I haven't finished this logic yet). 3. A separate tree makes it easier to use text tail page, [_etext, roundup(_etext, PMD_SIZE)], for modules and BPF programs. Does this make sense? Do you see other downsides with a second tree? Thanks, Song
