Date: Tue, 18 Mar 2014 19:38:03 +0000 From: "Meyer, Conrad" <conrad.meyer@isilon.com> To: John Baldwin <jhb@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: Bryan Drewery <bdrewery@freebsd.org> Subject: RE: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Message-ID: <A3CAF0E84A34A540B4C74454358E003F1292F043@MX103CL02.corp.emc.com> In-Reply-To: <201403181452.13685.jhb@freebsd.org> References: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com>, <201403181452.13685.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3CAF0E84A34A540B4C74454358E003F1292F043>