On 13.07.2018 21:31, Maxime Villard wrote: > I don't like the dbregs code. We unconditionally write into %dr6 and > %dr7 in > userret, that is, during each interruptible kernel->user transition. > > Some measurements with PMCs show that the loads of dr6/dr7 are one of the > first sources of recovery cycles during a build.sh - the cycles the CPU > spends > recovering from a mispredicted branch or a machine clear event. > > We lose many cycles down there. The code should have been written to just > switch dbregs during context switches, and not on each transition. > > It could be fixed, but since the PopSS vuln, we actually disabled dbregs by > default (they are now privileged), and I don't think we will ever re-enable > them, given the risk, even though we do have a mitigation for PopSS. > > So why not remove the code? I strongly object to the removal because of the debugging purposes. Their functionality is possible to simulate to some extend and with significant performance overhead (like execution in the single step move) I was benchmarking the existing code with DTrace and the overhead was negligible (like: 0,05% DR6 + 0,23% DR7). http://netbsd.org/~kamil/will-it-scale/open1_processes.svg I've initially started it with the FreeBSD-like approach to set them during cpu_switchto(9) but at that time I haven't solved mysterious panics. I still have some intermediate draft patch with the cpu_switch(9) implementation: http://netbsd.org/~kamil/dbg9.txt Feel free to optimize it, without the loss in functionality.
Attachment:
signature.asc
Description: OpenPGP digital signature