Hi Peter, > On Aug 22, 2022, at 9:56 AM, Song Liu <songliubraving@xxxxxx> 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 > 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? Did these make sense? Do you have future comments that I would address in future versions? Thanks, Song
