From owner-freebsd-arch@freebsd.org Mon Apr 16 16:40:25 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 0B795F920C4 for ; Mon, 16 Apr 2018 16:40:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 5C1CA7580B; Mon, 16 Apr 2018 16:40:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3GGeCWY009298 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Apr 2018 19:40:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3GGeCWY009298 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3GGeCjO009297; Mon, 16 Apr 2018 19:40:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Apr 2018 19:40:12 +0300 From: Konstantin Belousov To: Brooks Davis Cc: freebsd-arch@freebsd.org Subject: Re: Do fuswintr/suswintr make sense? Message-ID: <20180416164012.GJ1774@kib.kiev.ua> References: <20180416161012.GB44509@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180416161012.GB44509@spindle.one-eyed-alien.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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:40:25 -0000 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.