Instead of searching for a PVO entry before adding, take advantage of
the fact that RB_INSERT() returns NULL if it inserts, and the existing entry if
an entry exists, without inserting a new entry. This saves an extra tree
traversal in the cases where the PVO does not exist.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 25329 Build 23989: arc lint + arc unit
Event Timeline
Does this break PTE spills? This code path historically was involved in re-adding PVOs to the hashed page table on faults if they got spilled.
It shouldn't. I keep a "second chance" call in the case that a spill needs to take place. Is there an easy way to test that it doesn't break spills? I've been running this for about a month now with no problems.
Just make the page table size really small. There's a spill counter in the statistics; when it gets small enough, you should see it moving. If spill-handling doesn't work, and you have spills, everything breaks fast.
I just tested with a *very* small page table (0x8000 entries on a 256GB machine), and hit the 'moea64_pte_insert: overflow' panic, which you had mentioned a few years back is indicative of the PTEGs being filled with wired entries. Checking the statistics, I do see 0x38 overflows, and other statistics look accurate, too. I don't see anything bad in this patch, because the only thing it does is optimistically try to insert the PVO, and go through the normal logic if it already exists.