From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 01:36:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BEFF710 for ; Sat, 29 Mar 2014 01:36:34 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A68AFF0 for ; Sat, 29 Mar 2014 01:36:33 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s2T1aVT6078723; Fri, 28 Mar 2014 19:36:31 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201403290136.s2T1aVT6078723@elf.torek.net> From: Chris Torek To: Konstantin Belousov Subject: Re: slight problem with r254457 (kthread_add fix) In-reply-to: Your message of "Fri, 28 Mar 2014 16:24:02 +0200." <20140328142402.GX21331@kib.kiev.ua> Date: Fri, 28 Mar 2014 19:36:31 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 28 Mar 2014 19:36:32 -0600 (MDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 01:36:34 -0000 >The kernel-FPU code only exists for x86. I'm a bit surprised kernel-mode FPU is not supported on sparc64, but that does seem to be the case. (Surprising since there *is* code to use the VIS block-copy instructions, which use the FPU registers. This seems to be handled as a *very* special case though: it is called only through cpu_block_copy, and only for pmap_copy_page, which cannot be re-entered. So it's OK, if suboptimal. Using the VIS block-copy for other large copies should be a performance win, but this requires the ability to re-enter the routine.) Anyway, I'm mostly just saying that I can't check the remaining architectures as I don't know them well enough to tell. If you do, all is well there. :-) >Did you tested the patch I posted, for your situation ? It took a while to get back to, but yes, it works fine. [On cpu_throw:] >It seems that you formulation somewhat contradictory. The cpu_throw >is used only to do the last switch out of the exiting thread. Ah, I was thinking of the code paths that get there by calling sched_throw() with NULL, in the various mp_machdep.c files. You're looking at the one other code path that reaches sched_throw() (with a non-NULL argument), in thread_exit(): >And indeed, I think that there is a bug, on x86. The CR0.TS must be >cleared, and fpcurthread must be reset if current cpu still carries >FPU state of the curthread. At least, I do not see anything which >would guarantee that CLTS was done before cpu_throw. It turns out this is OK because of this: cpu_thread_exit(td); /* XXXSMP */ cpu_thread_exit() does an fpudrop if needed. (I don't think this is a particularly clean design, but it does work.) Chris