On Mon, Nov 7, 2022 at 9:39 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > > > Some imperfect things I can think of are(not related to this patchset): > > 1 Once a split happened, it remains happened. This may not be a big deal > > now with bpf_prog_pack and this patchset because the need to allocate a > > new order-9 page and thus cause a potential split should happen much much > > less; > > Not sure I follow, are you suggesting a order-9 (512 bytes) allocation would > trigger a split of the reserved say 2 MiB huge page? I think by order-9 allocation, Aaron meant 2MiB huge pages. The issue is that direct map split is one-way operation. If we set_memory_x() on one 4kB page out of a 1GB direct map, we will split it into 511x 2MiB pages and 512x 4kB pages. There is currently no way to regroup the 1GB page after set_memory_nx() on the page. Thanks, Song > > > 2 When a new order-9 page has to be allocated, there is no way to tell > > the allocator to allocate this order-9 page from an already splitted PUD > > range to avoid another PUD mapping split; > > 3 As Mike and others have mentioned, there are other users that can also > > cause direct map split. > > Hence the effort to generalize. > > Luis
