Date: Mon, 16 Apr 2018 19:40:12 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Brooks Davis <brooks@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Do fuswintr/suswintr make sense? Message-ID: <20180416164012.GJ1774@kib.kiev.ua> In-Reply-To: <20180416161012.GB44509@spindle.one-eyed-alien.net> References: <20180416161012.GB44509@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 16, 2018 at 04:10:12PM +0000, Brooks Davis wrote: > The fuswintr() and suswintr() are intended to be safe in interrupt > context. They are used in the profiling code and if they fail the code > falls back to triggering a trap with appropriate fields in struct > thread. This is fine as such, but amd64, arm, i386, and powerpc have > implementations that always fail. arm64, mips, riscv, and sparc64 all > add code to the trap handler to detect that this particular code has > faulted and return to the handler before doing and processing that might > result in a sleep. This optimization came from 4.4BSD. > > Does this optimization actually make sense in 2017, particularly > given that we're not taking advantage of it on x86 (and worse, our > implementations of return (-1) aren't inlined so they have cache > impacts)? I do not see a reason to keep them around. When I worked on copyin_nofault(), I specifically decided to not make it working from the interrupt handlers contexts. You need to be at the top of the kernel to be able to use it. So far there were no requests to change that. Since there is no other users of interrupt-safe usermode access, and since the only user cope with such access not working, I do not see a point.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180416164012.GJ1774>