- User Since
- Mar 12 2014, 1:00 AM (379 w, 2 d)
I did some more testing and now I think that the change is wrong. In particular, note that the RACCT_PCPU resource has RACCT_IN_MILLIONS attribute, which explains why this multiplication occurs.
Wed, Jun 16
Tue, Jun 15
If there are any tags, e.g., sponsored by, please add them to the review description and I'll commit.
Mon, Jun 14
I think checking for TAILQ_EMPTY(&vsi->sysctl_ctx) is probably a hack. sysctl_ctx_free() handles an empty queue perfectly well. The problem seems to be that the list is not initialized (with sysctl_ctx_init()) in some paths where sysctl_ctx_free() may be called.
Wed, Jun 9
Tue, Jun 8
- Compare initiator and target LDTs, and only reload if they match.
- Use an acquire load in the comparison.
I don't see any problems with the change, but note that this adds something like 30KB of data per thread. Probably not the end of the world but not ideal either.
Mon, Jun 7
Sun, Jun 6
Add comments to pmap_promote_l2() noting that we do not invalidate the TLB.
Preserve AF, DBM and RW flags when copying 2MB pages.
Fri, Jun 4
@whu ping. Do you plan to review this?
Try to better explain why it's ok to defer sfence.vma in pmap_promote_l2().
BTW, I did some buildkernel tests on a graviton instance and found no change in the number of promotions during a buildkernel. I can't think of any non-synthetic workloads that are likely to be affected in light of the fact that arm64 implements pmap_enter(psind=1), so faults on a shared mapping skip the promotion step, assuming that some entity triggered the initial promotion through writes.
Add a comment explaining why we downgrade protections and why we don't
I would suggest noting in the description/commit log message that this estimate is used only for short-lived processes.