From owner-svn-src-head@freebsd.org Sun Oct 22 18:19:47 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBCD0E2FAC2; Sun, 22 Oct 2017 18:19:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 8B6016FD91; Sun, 22 Oct 2017 18:19:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DC714260117; Sun, 22 Oct 2017 20:19:45 +0200 (CEST) Subject: Re: svn commit: r324863 - in head/sys: kern sys To: Mateusz Guzik Cc: Mateusz Guzik , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" References: <201710221342.v9MDguCC074682@repo.freebsd.org> <316ecd86-a508-fb36-e33c-ba32f5cb8073@selasky.org> From: Hans Petter Selasky Message-ID: <7f65c32c-4f7d-9424-f106-8b699d19f684@selasky.org> Date: Sun, 22 Oct 2017 20:17:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Sun, 22 Oct 2017 18:19:48 -0000 On 10/22/17 19:37, Mateusz Guzik wrote: > On Sun, Oct 22, 2017 at 6:59 PM, Hans Petter Selasky > wrote: > >> On 10/22/17 16:50, Mateusz Guzik wrote: >> >>> On Sun, Oct 22, 2017 at 04:24:41PM +0200, Hans Petter Selasky wrote: >>> >>>> On 10/22/17 15:42, Mateusz Guzik wrote: >>>> >>>>> Author: mjg >>>>> Date: Sun Oct 22 13:42:56 2017 >>>>> New Revision: 324863 >>>>> URL: https://svnweb.freebsd.org/changeset/base/324863 >>>>> >>>>> Log: >>>>> Change kdb_active type to u_char. >>>>> Fixes warnings from gcc and keeps the small size. Perhaps nesting >>>>> >>>> should be moved >>> >>>> to another variablle. >>>>> Reported by: ngie >>>>> >>>>> Modified: >>>>> head/sys/kern/subr_kdb.c >>>>> head/sys/sys/kdb.h >>>>> >>>>> Modified: head/sys/kern/subr_kdb.c >>>>> >>>>> ============================================================ >>> ================== >>> >>>> --- head/sys/kern/subr_kdb.c Sun Oct 22 12:12:52 2017 (r324862) >>>>> +++ head/sys/kern/subr_kdb.c Sun Oct 22 13:42:56 2017 (r324863) >>>>> @@ -50,7 +50,7 @@ __FBSDID("$FreeBSD$"); >>>>> #include >>>>> #endif >>>>> -bool __read_frequently kdb_active = 0; >>>>> +u_char __read_frequently kdb_active = 0; >>>>> static void *kdb_jmpbufp = NULL; >>>>> struct kdb_dbbe *kdb_dbbe = NULL; >>>>> static struct pcb kdb_pcb; >>>>> >>>>> Modified: head/sys/sys/kdb.h >>>>> >>>>> ============================================================ >>> ================== >>> >>>> --- head/sys/sys/kdb.h Sun Oct 22 12:12:52 2017 (r324862) >>>>> +++ head/sys/sys/kdb.h Sun Oct 22 13:42:56 2017 (r324863) >>>>> @@ -59,7 +59,7 @@ struct kdb_dbbe { >>>>> }; \ >>>>> DATA_SET(kdb_dbbe_set, name##_dbbe) >>>>> -extern bool kdb_active; /* Non-zero while in debugger. */ >>>>> +extern u_char kdb_active; /* Non-zero while in debugger. */ >>>>> extern int debugger_on_panic; /* enter the debugger on panic. >>>>> >>>> */ >>> >>>> extern struct kdb_dbbe *kdb_dbbe; /* Default debugger backend or >>>>> >>>> NULL. */ >>> >>>> extern struct trapframe *kdb_frame; /* Frame to kdb_trap(). */ >>>>> >>>>> >>>>> >>>> Should we add __aligned(8) to this definition? >>>> >>>> ./systm.h:#define __read_frequently >>>> >>> __section(".data.read_frequently") >>> >>>> >>>> It will prevent commonly read variables from residing in two different >>>> cache-lines on x86 and amd64 at least??? >>>> >>>> >>> I don't follow. This would *increase* alignemnt requirement and in >>> particular prevent bool variables from being put in consecutive bytes. >>> >>> To answer the question from your other e-mail, the bigger the type the >>> worse it is as it takes more space. The idea is to change all frequently >>> read and effectively bool variables from int to bool so that more of >>> them fit in one cacheline. >>> >>> Right now there is nothing to nicely sort them to get rid of holes, but >>> I'm tinkering with automagic size addition to section name. >>> >>> >> Hi, >> >> The point is that for x86 there is no alignment so the variables get >> packed back to back, and then you sometimes get not so smart layouts, like >> that an integer crosses a cache line. >> >> > They are aligned to their size and this creates holes, like here: > > ffffffff8112873c D kdb_active > ---------------- > ffffffff81128740 D audit_enabled > > Regarding automation: Maybe the idea behind sysinit can be used: >> sys/boot/usb/tools/sysinit.c >> > > I don't know how this can be plugged here. Would this require defining > variables elsewhere? > > Preferably they would be sorted by the linker. > Hi, If the linker supports this, that's the best. Else you'll need a custom tool. sysinit.c might give you some ideas how to implement it in a cross-OS way. --HPS