From owner-freebsd-arch@freebsd.org Mon Apr 16 16:10:13 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 358C0F8F66C for ; Mon, 16 Apr 2018 16:10:13 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4B046CA40 for ; Mon, 16 Apr 2018 16:10:12 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 28E285A9F13; Mon, 16 Apr 2018 16:10:12 +0000 (UTC) Date: Mon, 16 Apr 2018 16:10:12 +0000 From: Brooks Davis To: freebsd-arch@freebsd.org Subject: Do fuswintr/suswintr make sense? Message-ID: <20180416161012.GB44509@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:10:13 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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)? -- Brooks --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJa1MrjAAoJEKzQXbSebgfAHLAH/jFFiIiAB9NH0wQiLu8d1nLT ++fy2Ul9Gh4nqiDInBdyh8BpRpSd1ZipKhDgxo3NV+cGy6CH7OvTd+Y8G2py5N9v 3soc9GF+I1p9K/ByVEHco3bTbTOzhO5WEMHnjgCWyjFC7ZS46+taWGp4pqUMjvUO 3AWHNWJy/0hLcX9ecWSV91GRk1Um3CqZPB+G2fdF+ppitsYcRrNsnH98mUMFbttc xwnp+KPIxatNxcadZOc7elhaA5Asdoo+IbPK5erOefzKlukKlz60JJ/KWt5wv79+ qktA0x4EvwKRghYels7ffQcpDSWFPmCudfBC3DYpX/OqsEjMmZzJra3TQkHrXnY= =tbmI -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+--