From owner-svn-src-head@FreeBSD.ORG Fri Sep 5 02:50:44 2014 Return-Path: Delivered-To: svn-src-head@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 382E88CA; Fri, 5 Sep 2014 02:50:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EDE61A8F; Fri, 5 Sep 2014 02:50:44 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F3F8B968; Thu, 4 Sep 2014 22:50:43 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica Date: Thu, 04 Sep 2014 22:50:25 -0400 Message-ID: <3070015.668SIdAzOX@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <20140902154127.GD2737@kib.kiev.ua> References: <201408301748.s7UHmc6H059701@svn.freebsd.org> <201409021100.57493.jhb@freebsd.org> <20140902154127.GD2737@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 22:50:43 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 02:50:44 -0000 On Tuesday, September 02, 2014 06:41:27 PM Konstantin Belousov wrote: > On Tue, Sep 02, 2014 at 11:00:57AM -0400, John Baldwin wrote: > > I thought about that. I could easily make a parallel array, or perhaps > > use a separate 'susppcb' structure that includes a pcb and the savefpu > > union and change susppcbs to be an array of those. Which do you prefer? > > If we want to move some state out of the PCB on amd64 into this, then a > > separate struct for susppcbs might be the sanest. > > Yes, separate structure seems to be a way forward. Please see www.freebsd.org/~jhb/patches/susppcb.patch Note that I moved fpususpend() out into a C function on amd64 so that resumectx() could still operate on just a pcb. This also makes savectx and resumectx more symmetric and matches what I ended up doing on i386. This is tested for suspend and resume on both i386 and amd64. > FWIW, I do not understand the need for pcb in its current form, allocated > on the thread kernel stack, at all. It looks like a vestige of the > u-area, but serves no real purpose except to consume now precious stack > space. > > The idea of the part of the thread state that can be swapped out, together > with the stack, seems to become alien. Most of the thread state which is > not needed when the thread is not runnable, now goes to struct thread > anyway. Might be, we should move the pcb into td_md. People actively > object to the idea of the swappable kernel stack when they learn > hard that local vars cannot participate in the global lists. > > The only thing which is currently allocated below the pcb and which > seems to be reasonable to swap out, is the FPU context on amd64. I will defer to Peter on this as I believe he is the one that split the PCB out from the rest of the u-area (or what was left of it). My gut is that you are probably right and that it would be better to leave that room for the stack than to use it for the pcb. -- John Baldwin