Page MenuHomeFreeBSD

depessimize copyinstr_smap
ClosedPublic

Authored by mjg on Sep 6 2018, 5:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Feb 11, 5:44 PM
Unknown Object (File)
Tue, Feb 11, 1:46 AM
Unknown Object (File)
Tue, Feb 4, 8:10 AM
Unknown Object (File)
Jan 8 2025, 3:19 PM
Unknown Object (File)
Nov 28 2024, 7:28 PM
Unknown Object (File)
Oct 5 2024, 3:28 AM
Unknown Object (File)
Sep 20 2024, 10:29 PM
Unknown Object (File)
Sep 5 2024, 4:29 PM
Subscribers

Details

Summary

It was showing up on a name resolution-heavy benchmark (4% as reported by pmcstat, 0.7% after the patch).

The main reason was the slac/clac combo around each byte copy.

The patch reoders lables to remove a common case forward jump (the nosmap routine still suffers it) and englarges the smap-disabled region.

Note the current byte copy loop is still slow and is subject to being optimized later.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/amd64/amd64/support.S
929 ↗(On Diff #47757)

This leaks eflags.ac ?

sys/amd64/amd64/support.S
929 ↗(On Diff #47757)

If you mean this gives an exit which leaves smap disabled, then no. There are 2 ways out of stac-ed region: through this label and by falling down to copyinstr_succ. Both have clac. ​copyinstr_toolong_smap was introduced specifically to clac and and then fallback to previously seen ​copyinstr_toolong.

If that's not what you meant, please elaborate.

kib added inline comments.
sys/amd64/amd64/support.S
929 ↗(On Diff #47757)

Ah, I missed the _smap.

This revision is now accepted and ready to land.Sep 6 2018, 6:42 PM
This revision was automatically updated to reflect the committed changes.