Page MenuHomeFreeBSD

depessimize copyinstr_smap
ClosedPublic

Authored by mjg on Sep 6 2018, 5:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 2:22 AM
Unknown Object (File)
Dec 10 2023, 11:17 PM
Unknown Object (File)
Sep 6 2023, 9:18 AM
Unknown Object (File)
Jul 1 2023, 3:08 AM
Unknown Object (File)
May 9 2023, 2:00 AM
Unknown Object (File)
May 3 2023, 2:30 AM
Unknown Object (File)
Dec 23 2022, 3:34 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.