Page MenuHomeFreeBSD
Differential D4368

Use invlpg instead of total invalidation, when setting PG_G.
ClosedPublic
Actions

Authored by kib on Dec 4 2015, 8:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 19, 9:55 AM
Unknown Object (File)
Mon, Nov 11, 6:20 AM
Unknown Object (File)
Oct 22 2024, 3:57 AM
Unknown Object (File)
Oct 22 2024, 3:57 AM
Unknown Object (File)
Oct 22 2024, 3:56 AM
Unknown Object (File)
Oct 22 2024, 3:39 AM
Unknown Object (File)
Oct 4 2024, 7:00 AM
Unknown Object (File)
Oct 3 2024, 3:00 PM
View All 65 Files
Subscribers
cem
imp
jhb

Details

Reviewers
alc
Commits
rS291850: In the pmap_set_pg() function, which enables the global bit on the
Summary

Continuation of the D4346.

Diff Detail

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

Event Timeline

kib updated this revision to Diff 10722.Dec 4 2015, 8:35 AM
kib retitled this revision from to Use invlpg instead of total invalidation, when setting PG_G..
kib updated this object.
kib edited the test plan for this revision. (Show Details)
kib added a reviewer: alc.
kib set the repository for this revision to rS FreeBSD src repository - subversion.
kib added subscribers: jhb, cem.
Herald added a subscriber: imp. · View Herald TranscriptDec 4 2015, 8:35 AM
kib mentioned this in D4346: Fix pmap_invalidate_all() for kernel_pmap on x86 CPUs with PG_G support..Dec 4 2015, 8:36 AM
cem added inline comments.Dec 4 2015, 4:36 PM
sys/i386/i386/pmap.c
660–661 ↗(On Diff #10722)

Here we'll invalidate 512-1024 pages; is that really cheaper than an invltlb_glob()?

jhb added inline comments.Dec 4 2015, 5:38 PM
sys/i386/i386/pmap.c
641 ↗(On Diff #10722)

Note that this isn't a critical path, it's only called once during boot, so I'm not sure it's worth optimizing.

cem added inline comments.Dec 4 2015, 6:02 PM
sys/i386/i386/pmap.c
641 ↗(On Diff #10722)

Might as well boot as fast as possible.

alc added inline comments.Dec 4 2015, 6:03 PM
sys/i386/i386/pmap.c
641 ↗(On Diff #10722)

My issue with this isn't performance, but the logical inconsistency of issuing a PG_G flush when there are no PG_G mappings to flush. Except the ones created on the previous iteration.

660–661 ↗(On Diff #10722)

No, not really, and there is little state in the TLB worth preserving. I'll suggest this line:

invltlb(); /* Flush non-PG_G entries. */

Closed by commit rS291850: In the pmap_set_pg() function, which enables the global bit on the (authored by kib). · Explain WhyDec 5 2015, 8:47 AM
This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

PathSize
head/
sys/
i386/
i386/
4 lines

Diff 10765

View Options

head/sys/i386/i386/pmap.c

Loading...