From owner-freebsd-arch@freebsd.org Sun Nov 27 21:25:08 2016 Return-Path: Delivered-To: freebsd-arch@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 344F6C59063 for ; Sun, 27 Nov 2016 21:25:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C00111FDA for ; Sun, 27 Nov 2016 21:25:07 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id g23so16027469wme.1 for ; Sun, 27 Nov 2016 13:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=XJKsiso1p/xbH9qVgMnHpIImzVjJOenSQyWxn6ztDyI=; b=spgnNM/Ss1uEhOMhBDi/Mcy9HW77fYTJI1TloBbp1HWmjkkWjC6WnoyDx2cDhucoLv pcJtq0JunKyU3LxYxkwjEkyJherOgbNfYW4bE9p2U6jph5cR4QB8DrReB+z4Ot9UBAwZ T9IAgYO0yGwi+x2Tn/OFJ7cM2DoJiv5si0An7f/ixhgphY5pb3jexVmMAOQBk0nx1A3L Wvp1xnRloNRH0QWg6wLaSgeLPw/iU4tDJTbtRUrQKPflpQEFHoIiITu4lu1uuKngtnIt sHRvW8b36vZ9gzqvth4zjXcdJqXHjtB1UnFxwJ8DX4DEFqXVVXpDjhq5vLJvbtlvmsu1 WTfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=XJKsiso1p/xbH9qVgMnHpIImzVjJOenSQyWxn6ztDyI=; b=QlPT05H0kTM1d2Ijv2RPquQwJrGvwuL675J/1bGLzsn6+uD5CYcGj5V7nj4C5U5g0z pqyY+rrGpZxDiIudzjjoGByWM8ofqgvtWFgoSV0OYucr4cko3/RQMDH+m4M5OMljsKM4 WvWwX1y1G4OSEf4Tcd8BI5TQkJJ/CQlXs3K4IhpO6mHpR9hXH8HbvHOQ/XSrW5sKv2+k y6hxqYVj0AgG4rUWLBoQK9RTrsq9xvdcokvB7eUJewgGv4j+eaQE6v7WOrR1jPQ3+p9V o5BFibezN87bMN7sbYzL6yNdM6yJfG0ZFn5pVePNAF3zFSpyOXkexfA6nZQogH+S/KXo zuVA== X-Gm-Message-State: AKaTC007z1cM0I3nTp1z5ttGVplR64mXDhurywaTe12QQS+DY9AtbYq06wGt2o31XynzeA== X-Received: by 10.28.21.21 with SMTP id 21mr15304863wmv.132.1480281906033; Sun, 27 Nov 2016 13:25:06 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id yg1sm59021306wjb.12.2016.11.27.13.25.05 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 27 Nov 2016 13:25:05 -0800 (PST) Date: Sun, 27 Nov 2016 22:25:03 +0100 From: Mateusz Guzik To: freebsd-arch@freebsd.org Subject: __read_only in the kernel Message-ID: <20161127212503.GA23218@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 21:25:08 -0000 One of the standard problems in mpsafe kernels is false sharing. The somewhat standard way of combating parts of it for frequently read and rarely (if ever) modified variables is an annotation which puts them in a dedicated part of the binary and the somewhat standard name for a macro doing the work is __read_mostly. The FreeBSD kernel still does not have it and I think it's long overdue. Now, I don't know how to do it nicely in the linker script, in particular I don't know how get the cache line size. For testing purposes I hacked up a crap version below and verified it works fine. I hacked up the following crap version. Would be nice if someone with ld-clue fixed that up. I don't care about the header either. I just want the macro. :) diff --git a/sys/amd64/include/param.h b/sys/amd64/include/param.h index a619e395..ab66e79 100644 --- a/sys/amd64/include/param.h +++ b/sys/amd64/include/param.h @@ -152,4 +152,6 @@ #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS)) +#define __read_mostly __attribute__((__section__(".data.read_mostly"))) + #endif /* !_AMD64_INCLUDE_PARAM_H_ */ diff --git a/sys/conf/ldscript.amd64 b/sys/conf/ldscript.amd64 index 5d86b03..ae98447 100644 --- a/sys/conf/ldscript.amd64 +++ b/sys/conf/ldscript.amd64 @@ -151,6 +151,11 @@ SECTIONS KEEP (*(.gnu.linkonce.d.*personality*)) } .data1 : { *(.data1) } + .data_read_mostly : + { + *(.data.read_mostly) + . = ALIGN(64); + } _edata = .; PROVIDE (edata = .); __bss_start = .; .bss : diff --git a/sys/sys/param.h b/sys/sys/param.h index cf38985..dcd9526 100644 --- a/sys/sys/param.h +++ b/sys/sys/param.h @@ -360,4 +360,8 @@ __END_DECLS */ #define __PAST_END(array, offset) (((__typeof__(*(array)) *)(array))[offset]) +#ifndef __read_mostly +#define __read_mostly +#endif + #endif /* _SYS_PARAM_H_ */ -- Mateusz Guzik From owner-freebsd-arch@freebsd.org Mon Nov 28 07:20:40 2016 Return-Path: Delivered-To: freebsd-arch@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 D617BC58F1E for ; Mon, 28 Nov 2016 07:20:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 A1BA41914 for ; Mon, 28 Nov 2016 07:20:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 B67EA1FE024; Mon, 28 Nov 2016 08:20:37 +0100 (CET) Subject: Re: __read_only in the kernel To: Mateusz Guzik , freebsd-arch@freebsd.org References: <20161127212503.GA23218@dft-labs.eu> From: Hans Petter Selasky Message-ID: <90f7f729-8bd6-c3d9-648d-1d4fce0ac82c@selasky.org> Date: Mon, 28 Nov 2016 08:20:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161127212503.GA23218@dft-labs.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 07:20:40 -0000 On 11/27/16 22:25, Mateusz Guzik wrote: > One of the standard problems in mpsafe kernels is false sharing. > > The somewhat standard way of combating parts of it for frequently read > and rarely (if ever) modified variables is an annotation which puts > them in a dedicated part of the binary and the somewhat standard name > for a macro doing the work is __read_mostly. > > The FreeBSD kernel still does not have it and I think it's long overdue. > > Now, I don't know how to do it nicely in the linker script, in > particular I don't know how get the cache line size. > > For testing purposes I hacked up a crap version below and verified it > works fine. > > I hacked up the following crap version. Would be nice if someone with > ld-clue fixed that up. I don't care about the header either. > > I just want the macro. :) > > diff --git a/sys/amd64/include/param.h b/sys/amd64/include/param.h > index a619e395..ab66e79 100644 > --- a/sys/amd64/include/param.h > +++ b/sys/amd64/include/param.h > @@ -152,4 +152,6 @@ > #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ > || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS)) > > +#define __read_mostly __attribute__((__section__(".data.read_mostly"))) > + > #endif /* !_AMD64_INCLUDE_PARAM_H_ */ > diff --git a/sys/conf/ldscript.amd64 b/sys/conf/ldscript.amd64 > index 5d86b03..ae98447 100644 > --- a/sys/conf/ldscript.amd64 > +++ b/sys/conf/ldscript.amd64 > @@ -151,6 +151,11 @@ SECTIONS > KEEP (*(.gnu.linkonce.d.*personality*)) > } > .data1 : { *(.data1) } > + .data_read_mostly : > + { > + *(.data.read_mostly) > + . = ALIGN(64); > + } > _edata = .; PROVIDE (edata = .); > __bss_start = .; > .bss : > diff --git a/sys/sys/param.h b/sys/sys/param.h > index cf38985..dcd9526 100644 > --- a/sys/sys/param.h > +++ b/sys/sys/param.h > @@ -360,4 +360,8 @@ __END_DECLS > */ > #define __PAST_END(array, offset) (((__typeof__(*(array)) *)(array))[offset]) > > +#ifndef __read_mostly > +#define __read_mostly > +#endif > + > #endif /* _SYS_PARAM_H_ */ > Hi, You might needs to patch the linuxkpi /sys/compat/linuxkpi/ too, which also defines this macro. --HPS From owner-freebsd-arch@freebsd.org Mon Nov 28 07:24:00 2016 Return-Path: Delivered-To: freebsd-arch@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 40726C592E4 for ; Mon, 28 Nov 2016 07:24:00 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9D8F1F45 for ; Mon, 28 Nov 2016 07:23:59 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id m203so17316009wma.3 for ; Sun, 27 Nov 2016 23:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lt0H3CB8Ifks+YwAua0c/j03AtDPr8xAn5bXteJA/6g=; b=Dcr8pVJRw6h3vp3UbrNc3sdJAvsuE2BZ/CcFJ0uWrZ8/A3j5SWFDTY0UO0dYeOmRm4 92xCcPPlv1lC/CjissbC45Xzq9TiIsxAriGk6p4noRQtFkoJn6e6RKXT78qEHgG0z9eb dwtXUSQuBtQ4GPpzfhYrvJRaQCUrfURpMzaZx2yCqk6KQmwqqWtP7MNvtQ8wwO9ueWvI 2U1M5cC5eJ9dbjFRpSpAoVwRkhqnJJrsv47veF5QXi03b7uds+5CarW/0nIVO8k16PgR 3zQvXLmLSnvah/bw5jv6SEruDqoTHgCu7QTWTvwY0AVXq+9mQDORX19M6AP4XrZdF9vv Ko3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lt0H3CB8Ifks+YwAua0c/j03AtDPr8xAn5bXteJA/6g=; b=Q5Gl5wYd2L4x/uxyW/V3XzS3MbsQHgbqSS+HiX04Dy4Y6e9TKZyNj+ByMvFoSK19Dc NPW6OE40woHa3ei+0+D5BT/Tjdy8GWfXrx1ihr+RR8radPhHXiYgRuWL5IAmgcqTP9RY sHKrmnlmgHixlkgMvfn149sZFczrUdGssI1vU9aXA7dqG7BOKRRVEfJ7cxOJ/Rk2oPd1 MPVC2O1w3LoCPZ1859838dlWg44m3omx0XDp1t1etY9aRZumhlHSLZwv8imoENi7+b4Z S04cF9hwInpU5VovkKm1plggA+6lu6AVxM7fVA/slNKTd1lOHXECUH2HgZbNvHZeRPkg DVKg== X-Gm-Message-State: AKaTC00nUEGoindI8JmLY9oRse+pOEO8GPA9OxrhjkIviz3esu1/cDKRBZ0toS6ECxybaA== X-Received: by 10.28.131.1 with SMTP id f1mr18838318wmd.43.1480317838318; Sun, 27 Nov 2016 23:23:58 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id f134sm27341417wmf.19.2016.11.27.23.23.56 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 27 Nov 2016 23:23:56 -0800 (PST) Date: Mon, 28 Nov 2016 08:23:54 +0100 From: Mateusz Guzik To: Hans Petter Selasky Cc: freebsd-arch@freebsd.org Subject: Re: __read_only in the kernel Message-ID: <20161128072354.GB23218@dft-labs.eu> References: <20161127212503.GA23218@dft-labs.eu> <90f7f729-8bd6-c3d9-648d-1d4fce0ac82c@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <90f7f729-8bd6-c3d9-648d-1d4fce0ac82c@selasky.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 07:24:00 -0000 On Mon, Nov 28, 2016 at 08:20:21AM +0100, Hans Petter Selasky wrote: > On 11/27/16 22:25, Mateusz Guzik wrote: > >+#define __read_mostly __attribute__((__section__(".data.read_mostly"))) > > You might needs to patch the linuxkpi /sys/compat/linuxkpi/ too, > which also defines this macro. > Oh, indeed: sys/dev/drm2/drm_os_freebsd.h:#define __read_mostly Thanks, -- Mateusz Guzik From owner-freebsd-arch@freebsd.org Mon Nov 28 08:31:19 2016 Return-Path: Delivered-To: freebsd-arch@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 B26F8C57ABA for ; Mon, 28 Nov 2016 08:31:19 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79A76139F for ; Mon, 28 Nov 2016 08:31:19 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x231.google.com with SMTP id a10so109248064ywa.3 for ; Mon, 28 Nov 2016 00:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dsrpvqfqzKWt8T4hoD/1ilRInCnhE9TonEdOHFtlIUk=; b=Wqvess5TTorwG+EIHrRTc6HdrvARuneZ7J4ZSShtH8hBCaAFISjZN0q8ClO8TOTrH3 xCeL0rxISGxAM+HIaTm1g7/Eb6k1A3rSdQa++8xSfqQcOuvbMGucIklyiHg2p+sVoWDa l/izT1M4koqLJmWrvjuHPvtcRocKBxxd6whqxdi+/N6VCxe8n+8LtpP6n0jRFmbV1FtW 5mpgJZFFnKkRVa/TJ5DVjBBWpH8fbkH8waZljIBjmUx3yyFYV+QuguwLrblZNrQ3phxj quLpuRLzossB7gwnKPZ5RfrmR2kysH+dopEyhjUzymSb28ClsqqJpcJNzEOtZFDyiC4K X1pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dsrpvqfqzKWt8T4hoD/1ilRInCnhE9TonEdOHFtlIUk=; b=WyqpINdLSvhj60P/5LSuJMtEYT/EhlLpEnmGdiyefCaTUxRTckrOPBYVrPOabKflLR ktEjGhWEoa8IFOVGLuU1OgkQQ7TVVXRMOxKYc3KykEHsBgSOTIiHNeMS/NyWYxzr9dzM T31Ev5sTpKn2r50XtV6IrIJl0Bj+vNyRQMDybkB3EHxQoM+kYa318ySGi1rFU6L8aizn DLE0WdIvfcGu2OChm0eP4GhtFttAttJOSz51NGH1nXv3kCDs1DTvSVMdg6QP7PS38Xbu 5/s9WX2mSNNHbHqiGRgowRAtjPauZWgiALvpG3z6xglxAey9I24Z7D2RK2uXPpudL78H KmQg== X-Gm-Message-State: AKaTC02Wwcxfj1R5vDOp9BIz2idR3sgcc9VPfNwNqK5aQz3IvP2rv2rhzlWaGs1NEhNMzu0eRZE6yArdT1aqnw== X-Received: by 10.129.88.213 with SMTP id m204mr23378204ywb.130.1480321878379; Mon, 28 Nov 2016 00:31:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.31.213 with HTTP; Mon, 28 Nov 2016 00:30:47 -0800 (PST) In-Reply-To: <20161127212503.GA23218@dft-labs.eu> References: <20161127212503.GA23218@dft-labs.eu> From: Ed Schouten Date: Mon, 28 Nov 2016 09:30:47 +0100 Message-ID: Subject: Re: __read_only in the kernel To: Mateusz Guzik Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 08:31:19 -0000 Hi Mateusz, 2016-11-27 22:25 GMT+01:00 Mateusz Guzik : > The somewhat standard way of combating parts of it for frequently read > and rarely (if ever) modified variables is an annotation which puts > them in a dedicated part of the binary and the somewhat standard name > for a macro doing the work is __read_mostly. Out of curiosity, what is the advantage of doing this? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-arch@freebsd.org Mon Nov 28 15:16:35 2016 Return-Path: Delivered-To: freebsd-arch@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 6E80AC59C1D for ; Mon, 28 Nov 2016 15:16:35 +0000 (UTC) (envelope-from citrin+bsd@citrin.ru) Received: from hz.citrin.ru (hz.citrin.ru [88.198.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 365211E6E for ; Mon, 28 Nov 2016 15:16:34 +0000 (UTC) (envelope-from citrin+bsd@citrin.ru) Received: from x220.lan (c-24-60-168-172.hsd1.ct.comcast.net [24.60.168.172]) by hz.citrin.ru (Postfix) with ESMTPSA id EE85128A662 for ; Mon, 28 Nov 2016 15:16:24 +0000 (UTC) Subject: Re: __read_only in the kernel To: freebsd-arch@freebsd.org References: <20161127212503.GA23218@dft-labs.eu> From: Anton Yuzhaninov Message-ID: Date: Mon, 28 Nov 2016 10:16:22 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrin.ru; s=s0; t=1480346185; bh=suc0JRtPpouuCV8H0a/7bGwB3VN/Lw/wBqkLm7og8Xg=; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=AOG+OC+6fckaKJFowxBKFg1SOHEMyCAoSd47ogqLaBCEWrULB29fVWGcU9NAY4FpMhhXR6FRVafAiUW6CYyUUrJdtdQ5FBhmn99bhIfx8TluBWqR5TpnIf3wWWtzhTCuGLFfihCHztNZuD/48eF+D15uyfa3hRwnnQSdIc/fQNM= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 15:16:35 -0000 On 11/28/16 03:30, Ed Schouten wrote: > 2016-11-27 22:25 GMT+01:00 Mateusz Guzik : >> The somewhat standard way of combating parts of it for frequently read >> and rarely (if ever) modified variables is an annotation which puts >> them in a dedicated part of the binary and the somewhat standard name >> for a macro doing the work is __read_mostly. > > Out of curiosity, what is the advantage of doing this? If a variable which read often shares CPU cache line with a variable updated often we have performance degradation. Each time second variable is updated first (read mostly) unnecessary flushed from CPU cache. Some data structures already aligned by cache line size to avoid false sharing, but moving read only / read mostly variables to separate section allows to avoid false sharing without spending memory on alignment (and alignment not always helps to avoid false sharing AFAIK). From owner-freebsd-arch@freebsd.org Mon Nov 28 16:27:12 2016 Return-Path: Delivered-To: freebsd-arch@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 59411C5ACF5 for ; Mon, 28 Nov 2016 16:27:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2410F1289 for ; Mon, 28 Nov 2016 16:27:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x233.google.com with SMTP id a124so238385531ioe.2 for ; Mon, 28 Nov 2016 08:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sUK02J89jNKc2VNGMnVqXL7BVSm+wtvaK3MJOzU9mWc=; b=IQbYyJJbhWwTA+OcU3q8lLfSmsN2tmWZiJiCbqhikwZoKgV7bwDu3BJfJmL46Haq8h s/eJ4YbbGiQAl2FNk4N5/B4bslKPEVHadCmQgshWCtUJTBey7dYqK4Fd8kxXLSZGAeWl 37916StOUwSgMPsjGnHoNZ5QxxWgXBrtxYyyf/Gcqfi2Xa9D3aD+60zv/1l8+XGV+QT9 wODP4OmYmbSAFX+zSEmieVFDs2flSnuUipMkXQ78QFapaILc1yF27pN/EC5guZAh/4s0 Z77KU4R0aadK3fxB3AdbGNfxYUGoPQI5pWQ4z1Zd6oSKziswn7m+UJJW209sruL9x8z4 ROwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sUK02J89jNKc2VNGMnVqXL7BVSm+wtvaK3MJOzU9mWc=; b=h1poNsV1Xrc8OoUb32pb5Wm85uhvrOf8HPHhxJ/E9lDlE9jxE2xbVDBtolxvOSivHm EFmGXa0ylaiRDeBwH0vBhPe0T1nEcQ9iu/nImGUi6XowUVzKgV95b+YJTmO0rBSonWlY SSboWEhs2cXQYn3bn6xaCbKB3iWKBa5XBgcxfXm4SqjVzrZPqbH+s/w3eTmAaR5Psu0+ gj8crhx14dVC98d6mDNANM2Rkn5BB0E9csP4OXUU+qfkEV3I6rR4qyuwKwi/3M/t733m z608ZtA5h07dhOSsprbCNsYXQYnZDMckwOAsrfYwxEVgRmJKiCeToKPNX6hfls5BM42U 9DcQ== X-Gm-Message-State: AKaTC00j1krDA9T+4JoUmEBUrTr0dxDraTt/EFkIsdlbtmtRkwaxGhwvkBj9BQFEqgiN8qKjuLXaExHOJUXG/w== X-Received: by 10.36.61.146 with SMTP id n140mr19263593itn.78.1480350431488; Mon, 28 Nov 2016 08:27:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Mon, 28 Nov 2016 08:27:10 -0800 (PST) In-Reply-To: References: <20161127212503.GA23218@dft-labs.eu> From: Adrian Chadd Date: Mon, 28 Nov 2016 08:27:10 -0800 Message-ID: Subject: Re: __read_only in the kernel To: Anton Yuzhaninov Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 16:27:12 -0000 .. and it makes it easy to see (a) whether a variable has it, and (b) whether a variable doesn't - just use grep. -a On 28 November 2016 at 07:16, Anton Yuzhaninov wrote: > On 11/28/16 03:30, Ed Schouten wrote: >> >> 2016-11-27 22:25 GMT+01:00 Mateusz Guzik : >>> >>> The somewhat standard way of combating parts of it for frequently read >>> and rarely (if ever) modified variables is an annotation which puts >>> them in a dedicated part of the binary and the somewhat standard name >>> for a macro doing the work is __read_mostly. >> >> >> Out of curiosity, what is the advantage of doing this? > > > If a variable which read often shares CPU cache line with a variable updated > often we have performance degradation. Each time second variable is updated > first (read mostly) unnecessary flushed from CPU cache. > > Some data structures already aligned by cache line size to avoid false > sharing, but moving read only / read mostly variables to separate section > allows to avoid false sharing without spending memory on alignment (and > alignment not always helps to avoid false sharing AFAIK). > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Wed Nov 30 01:10:40 2016 Return-Path: Delivered-To: freebsd-arch@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 3C77EC5B851 for ; Wed, 30 Nov 2016 01:10:40 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5F9D1158 for ; Wed, 30 Nov 2016 01:10:39 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id a20so27116260wme.2 for ; Tue, 29 Nov 2016 17:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=F3kuuEckqVQcGb92sOfp67b6Fhe8COZOmdGcEzKZnU8=; b=B3B4K+d8fmHiLZDCBAQpwfUXxWO2xQJ5cm9iWoq+X9BwO+cl00UPNa4JkcOZNx1OvT dam7YhRsoNAMRcwS/wSyC4PW6xx/7APxv+1v2vuLpMpacGHAS3yZCDN9wOFeWk5gVl9F +1V3yUa4ceo/1VOnoRTynSgysSFE2QlL0ebhc444FvrGtE7CVF4fdNzsMjM2YaPdxyoZ bfgYbFJU+lj5ZBHMWb0wMBo2eOcC1fqzH+Tmel2Vbu74nBDzX5jpo552WReOKJq9Swl9 dIfi2Dmh5L7Pz277LZeBiD2bpRQXTL/dTG0zCHR0U5uCyqAteqgUZzszTCuMtLgg0cil /vng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=F3kuuEckqVQcGb92sOfp67b6Fhe8COZOmdGcEzKZnU8=; b=GCYDaJ9pQpHGY0cqjAOuqk2kGF6MxmM1zJm9MLldjZxYk1CdzrodEA5fbi+EAAtRbI Sd0mivfbUfXSQ86IujLSycF3D7AIKW7WDI9hwBeNgaFbJLdmPZc1mJky1AU0xmtGfpFm joZ8HywifGixiP8tBFzHifN16x8kT7SNciycSG0FKPRRV6GTs4078vRhaMJKxkgSa5Bg f4qJ9tS7qXMDerVyNe461sauJMwr+OHX1TZNEmN9T1XG1BT09e4RnKE9Sj1B0o2Ci1Uq WC6wWQODhgq8LtLoMGK8Cnpi6btUYsXAGwN6Lz5Vxb4lupXecI2SncIg29ftpOB4J4Lr peeA== X-Gm-Message-State: AKaTC02JDRMAXv4fzXi/YID5qzyuxaMdG7B0f9N8Up/d4uiTnHA6/7O0fCWruRHOYnt0oA== X-Received: by 10.28.230.197 with SMTP id e66mr27674784wmi.12.1480468237440; Tue, 29 Nov 2016 17:10:37 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id j1sm70422492wjm.26.2016.11.29.17.10.36 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 29 Nov 2016 17:10:36 -0800 (PST) Date: Wed, 30 Nov 2016 02:10:34 +0100 From: Mateusz Guzik To: freebsd-arch@freebsd.org Subject: Re: __read_only in the kernel Message-ID: <20161130011033.GA20999@dft-labs.eu> References: <20161127212503.GA23218@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161127212503.GA23218@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 01:10:40 -0000 I officially threaten to commit this by Friday. __read_mostly-ification of certain vars will follow. stable/11 and stable/10 will get the #define __read_mostly bit for convenience, but the feature itself will likely get mfced to 11. On Sun, Nov 27, 2016 at 10:25:03PM +0100, Mateusz Guzik wrote: > One of the standard problems in mpsafe kernels is false sharing. > > The somewhat standard way of combating parts of it for frequently read > and rarely (if ever) modified variables is an annotation which puts > them in a dedicated part of the binary and the somewhat standard name > for a macro doing the work is __read_mostly. > > The FreeBSD kernel still does not have it and I think it's long overdue. > > Now, I don't know how to do it nicely in the linker script, in > particular I don't know how get the cache line size. > > For testing purposes I hacked up a crap version below and verified it > works fine. > > I hacked up the following crap version. Would be nice if someone with > ld-clue fixed that up. I don't care about the header either. > > I just want the macro. :) > > diff --git a/sys/amd64/include/param.h b/sys/amd64/include/param.h > index a619e395..ab66e79 100644 > --- a/sys/amd64/include/param.h > +++ b/sys/amd64/include/param.h > @@ -152,4 +152,6 @@ > #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ > || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS)) > > +#define __read_mostly __attribute__((__section__(".data.read_mostly"))) > + > #endif /* !_AMD64_INCLUDE_PARAM_H_ */ > diff --git a/sys/conf/ldscript.amd64 b/sys/conf/ldscript.amd64 > index 5d86b03..ae98447 100644 > --- a/sys/conf/ldscript.amd64 > +++ b/sys/conf/ldscript.amd64 > @@ -151,6 +151,11 @@ SECTIONS > KEEP (*(.gnu.linkonce.d.*personality*)) > } > .data1 : { *(.data1) } > + .data_read_mostly : > + { > + *(.data.read_mostly) > + . = ALIGN(64); > + } > _edata = .; PROVIDE (edata = .); > __bss_start = .; > .bss : > diff --git a/sys/sys/param.h b/sys/sys/param.h > index cf38985..dcd9526 100644 > --- a/sys/sys/param.h > +++ b/sys/sys/param.h > @@ -360,4 +360,8 @@ __END_DECLS > */ > #define __PAST_END(array, offset) (((__typeof__(*(array)) *)(array))[offset]) > > +#ifndef __read_mostly > +#define __read_mostly > +#endif > + > #endif /* _SYS_PARAM_H_ */ > -- > Mateusz Guzik -- Mateusz Guzik From owner-freebsd-arch@freebsd.org Wed Nov 30 21:35:24 2016 Return-Path: Delivered-To: freebsd-arch@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 A806BC5D9A1 for ; Wed, 30 Nov 2016 21:35:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8CC1DAA for ; Wed, 30 Nov 2016 21:35:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c110-21-100-78.carlnfd1.nsw.optusnet.com.au [110.21.100.78]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 361B51042861; Thu, 1 Dec 2016 08:05:55 +1100 (AEDT) Date: Thu, 1 Dec 2016 08:05:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mateusz Guzik cc: freebsd-arch@freebsd.org Subject: Re: __read_only in the kernel In-Reply-To: <20161130011033.GA20999@dft-labs.eu> Message-ID: <20161201070246.S1023@besplex.bde.org> References: <20161127212503.GA23218@dft-labs.eu> <20161130011033.GA20999@dft-labs.eu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=BKLDlBYG c=1 sm=1 tr=0 a=uGjuzT6u7JdBDS7kH8taPg==:117 a=uGjuzT6u7JdBDS7kH8taPg==:17 a=kj9zAlcOel0A:10 a=zKwlznhDgV4ePe7pBxgA:9 a=5hRXF1yCUoz3ZGdL:21 a=PV8UcHJ9p_xyYgZ2:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 21:35:24 -0000 On Wed, 30 Nov 2016, Mateusz Guzik wrote: > I officially threaten to commit this by Friday. It has too high a density of style bugs to commit. >> diff --git a/sys/amd64/include/param.h b/sys/amd64/include/param.h >> index a619e395..ab66e79 100644 >> --- a/sys/amd64/include/param.h >> +++ b/sys/amd64/include/param.h >> @@ -152,4 +152,6 @@ >> #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ >> || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS)) >> >> +#define __read_mostly __attribute__((__section__(".data.read_mostly"))) >> + >> #endif /* !_AMD64_INCLUDE_PARAM_H_ */ 1. Hard-coded gccism: __attribute__(). 1a. Non-use of the FreeBSD macro __section() whose purpose is to make it easy to avoid using __attribute__() for precisely what it is used for here. 2. Misplaced definition. Such definitions go in . This one has no dependencies on amd64 except possibly for bugs elsewhere, but is only in an amd64 header. __section() has no dependencies on anything, but its contents may be MD. Here the contents are not very MD. already refers to the magic sections ".gnu.warning." # sym without even using its own macro (it uses hard-coded __asm__() and also doesn't even use the preferred FreeBSD spelling __asm()). It isn't clear what prevents these hard-coded gccisms from being syntax errors in the lint case where __section() is defined as empty to avoid syntax errors. According to userland tests, section statements like the above and the ones in don't need any linker support to work, since they create sections as necessary. So the above definition in should almost perfectly for all arches, even without linker support. Style bug (1) is smaller if it is there. >> diff --git a/sys/conf/ldscript.amd64 b/sys/conf/ldscript.amd64 >> index 5d86b03..ae98447 100644 >> --- a/sys/conf/ldscript.amd64 >> +++ b/sys/conf/ldscript.amd64 >> @@ -151,6 +151,11 @@ SECTIONS >> KEEP (*(.gnu.linkonce.d.*personality*)) >> } >> .data1 : { *(.data1) } >> + .data_read_mostly : >> + { >> + *(.data.read_mostly) >> + . = ALIGN(64); >> + } >> _edata = .; PROVIDE (edata = .); >> __bss_start = .; >> .bss : For arches without this linker support, the variables would be grouped but not aligned so much. Aligning the subsection seems to be useless anyway. This only aligns the first variable in the subsection. Most variables are still only aligned according to their natural or specified alignment. This is rarely as large as 64. But I think variables in the subsection can be more aligned than the subsection. If they had to be (as in a.out), then it is the responsibility of the linker to align the subsection to more than the default if a single variable in the subsection needs more than the default. >> diff --git a/sys/sys/param.h b/sys/sys/param.h >> index cf38985..dcd9526 100644 >> --- a/sys/sys/param.h >> +++ b/sys/sys/param.h >> @@ -360,4 +360,8 @@ __END_DECLS >> */ >> #define __PAST_END(array, offset) (((__typeof__(*(array)) *)(array))[offset]) >> >> +#ifndef __read_mostly >> +#define __read_mostly >> +#endif >> + >> #endif /* _SYS_PARAM_H_ */ Since the definition was misplaced in only the amd64 param.h, you needed this hack to define it for other arches. The general definition would be misplaced here too, like most definitions in this file. __read_mostly() is not a system parameter. Fortunately, it also doesn't use any system parameters, so it can go in or better if kernel-only. It is close to needing a parameter for alignment. Bruce