From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:38:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13C82EC0; Tue, 18 Mar 2014 19:38:16 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFCB42D7; Tue, 18 Mar 2014 19:38:15 +0000 (UTC) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2IJcDnw017768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2014 15:38:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2IJcDnw017768 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1395171494; bh=SWajVKUlJPqQfW9yw9dmO7pseBw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=QISudq4EC/4QTC+Kz7masX2kjsr2tUvL4rjmUCYmwJLojFMRJCPo+YuqeQ/SxbP60 cKEhjl3zmU+Co/F6Mh4LpeuOs4gXdNxRMUaoQdXwYxss0sDWQ7zK7m+zaA9sJenPhY gfIWnF650KDFQe7IV+SAI0L/5FMa/7hM5g5Qir0Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2IJcDnw017768 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 18 Mar 2014 15:38:05 -0400 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2IJc4V4022666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 15:38:04 -0400 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 18 Mar 2014 15:38:04 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 15:38:04 -0400 From: "Meyer, Conrad" To: John Baldwin , "freebsd-hackers@freebsd.org" Subject: RE: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Thread-Topic: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Thread-Index: AQHPP7ORFQWDnOxBbUqa6FTdfgehbJrnegCA///IprI= Date: Tue, 18 Mar 2014 19:38:03 +0000 Message-ID: References: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com>, <201403181452.13685.jhb@freebsd.org> In-Reply-To: <201403181452.13685.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.37.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: Bryan Drewery 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: Tue, 18 Mar 2014 19:38:16 -0000 From: John Baldwin [jhb@freebsd.org]=0A= Sent: Tuesday, March 18, 2014 11:52 AM=0A= To: freebsd-hackers@freebsd.org=0A= Cc: Meyer, Conrad; Bryan Drewery=0A= Subject: Re: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when refe= rencing thread's pcpu=0A= =0A= > > - How atomic does PCPU_INC() need to be? It looks like it updates cpu= -local=0A= > > counters; as long as it's a single asm instruction, should it be fi= ne=0A= > > w.r.t. interrupts? The existing implementation does NOT use the 'lo= ck; ' prefix.=0A= > =0A= > I think a single instruction is fine.=0A= =0A= Unfortunately, I'm seeing crashes under stress in internal testing that I c= an't attribute to anything else. I'm not sure why Clang would generate more= than one instruction for any of this, but I haven't probed too deeply.=0A= =0A= > > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h=0A= > > index fe898e9..68892fc 100644=0A= > > --- a/sys/amd64/include/pcpu.h=0A= > > +++ b/sys/amd64/include/pcpu.h=0A= > > +#define curthread __extension__ ({ = \=0A= > > + *((volatile __pcpu_type(pc_curthread) __GS_RELATIVE *) \= =0A= > > + __pcpu_offset(pc_curthread)); \= =0A= > > +})=0A= > =0A= > Would be nice to not lose the __pure2 attribute for curthread (you=0A= > might need it to still be an inline function to keep that)=0A= =0A= Yeah, I think you would need it to be a function for that. As is I don't th= ink Clang has any reason to optimize away redundant loads from a volatile p= ointer.=0A= =0A= Thanks,=0A= Conrad=