https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 57856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57856&action=edit quick skip-list patch Before: > /usr/bin/time ./cc1plus -quiet -o /dev/null /tmp/a-test-poly.ii -O 173.29user 3.25system 2:56.59elapsed 99%CPU (0avgtext+0avgdata 11311472maxresident)k 0inputs+0outputs (0major+2867887minor)pagefaults 0swaps After: > /usr/bin/time ./cc1plus -quiet -o /dev/null /tmp/a-test-poly.ii -O 161.23user 3.15system 2:44.44elapsed 99%CPU (0avgtext+0avgdata 11308852maxresident)k 0inputs+0outputs (0major+2868137minor)pagefaults 0swaps The patch uses the ->prev pointer to point to the previous entry of the next entry with differing ->bytes. I re-compute the pointers from scratch during release_pages and update during alloc/free but do not merge ranges when allocating. It would be possible to compute/update the skip list pointer during the walk itself at a bit of extra cost there. As said, when we see to maintain a sorted free_pages list this might speed up the walk some more as we can stop after checking the right-size chunk. Doing a better job in release_pages for the madvise case would be good as well. I wonder if anybody has a preference / priority?
