From owner-freebsd-current Sun Jan 28 20:52: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 1E26337B402 for ; Sun, 28 Jan 2001 20:51:47 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id PAA28199; Mon, 29 Jan 2001 15:51:06 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01JZHGWF7BJ4I8S1NY@cim.alcatel.com.au>; Mon, 29 Jan 2001 15:50:23 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f0T4oY565590; Mon, 29 Jan 2001 15:50:34 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 29 Jan 2001 15:50:33 +1100 From: Peter Jeremy Subject: Re: kernel threading: the first steps [patch] In-reply-to: <200101270833.AAA75738@InterJet.elischer.org>; from julian@elischer.org on Sat, Jan 27, 2001 at 12:33:23AM -0800 To: Root Dude Cc: current@FreeBSD.ORG Mail-followup-to: Root Dude , current@FreeBSD.ORG Message-id: <20010129155033.K52423@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200101270833.AAA75738@InterJet.elischer.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-Jan-27 00:33:23 -0800, Root Dude wrote: >I've broken the proc structure into 4 structures. Leaving aside the issue of whether or your efforts were a waste of time, I have some comments on the ordering of fields. Since the fields are being re-arranged anyway, I'd like to suggest that the implementation characteristics be taken into account. I'm mainly thinking of padding between fields here. A second, far less important issue is the interaction between field order and code size on the IA32. Given that most structure references are base+offset, there's an extra 3-byte overhead in accessing fields more than 127 bytes from the pointer - there's no direct speed penalty except on the 80386, but there is an indirect penalty for larger code (ie bigger cache footprint). This suggests that fields with a high static reference count should be towards the front of structures. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message