When lookup_range is invoked with a lock held, the popmap field of a level-0 parent node can be used to find the next null child (if any) of that parent, allowing null checks to be removed from the loop and for the compiler to perform some loop unrolling.
Details
Details
- Reviewers
alc markj kib - Commits
- rG6fd6c29a236c: pctrie: use popmap in locked lookup_range
A test ran buildworlds repeatedly, and counted calls to lookup_range for both the (locked) iterator version and the unlocked version. Performance for the locked version improved very slightly.
Original:
iter_calls: 4429708 61.276887325304514
iter_calls: 4154212 59.70931430557709
iter_calls: 4150022 60.694023549754675
iter_calls: 4150131 60.67953228464354
unlocked_calls: 840221 321.7100846086922
unlocked_calls: 782491 315.57590183145874
unlocked_calls: 783626 329.88843147113545
unlocked_calls: 786474 333.208179799968
Modified:
iter_calls: 4421212 60.891263300651495
iter_calls: 4157109 59.29220956198166
iter_calls: 4151355 59.99452805168433
iter_calls: 4151863 59.19281801928435
unlocked_calls: 839892 304.41711672453124
unlocked_calls: 781278 325.4182877285678
unlocked_calls: 781892 326.2977495613205
unlocked_calls: 781495 320.9273175132279
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
vm_page: use popmap in locked lookup_range
pctrie: ... would seem to make more sense as a commit title.
| sys/kern/subr_pctrie.c | ||
|---|---|---|
| 633–643 | ||
| sys/kern/subr_pctrie.c | ||
|---|---|---|
| 648 | Why do you continue the fill for PCTRIE_LOCKED case ? Isn't it results in NULL slots in value[]? | |
| sys/kern/subr_pctrie.c | ||
|---|---|---|
| 648 | In the PCTRIE_LOCKED case, I know that val is not NULL, because I computed end to make sure that the iteration stopped before reaching the first NULL. | |
| sys/kern/subr_pctrie.c | ||
|---|---|---|
| 648 | Assert that, and explain in comment, please? | |
Comment Actions
Add comments to explain end calculation. Add KASSERT to check that copied pages are not NULL.
Comment Actions
@alc asks for a more commenting about why this code treats SMR and locked diferently. I oblige.