Thread: Re: [PATCHES] Reorganization of spinlock defines
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Prompted by confusion over Itanium/Opterion, I have written a patch to > > improve the way we define spinlocks for platforms and cpu's. > > The main.c part of the patch strikes me as irrelevant to the claimed > purpose and unlikely to accomplish anything except breaking things. > Do you have a system the main.c "__alpha" code is relevant to, on which > to test that you did not break it? > > Other than that, it looks like basically a good idea. But... I was going to have an alpha guy test it --- that was the one change I wasn't sure about. We did test for __alpha__ all over the port/*.h files, so it wasn't clear which alpha's were being hit. I can throw in a comment and skip that part --- not sure. > > I plan to apply this to 7.4. > > This seems like living dangerously. You do realize that this patch will > invalidate our trust that the code works on every single supported > platform? I think beta3 may be a bit late in the game for this sort of > thing, because we've already gotten a good bit of the testing we can > expect to get for lesser-used platforms during this beta cycle. > > At the very least I'd like to see the decision discussed on -hackers > and not buried in -patches. The problem with waiting for 7.5 is that we will have no error reporting when our non-spinlock code is being executed, and with Opteron/Itanium, it seems like a good time to get it working. We had the FreeBSD report with not finding Opteron/Itanium, and that's what got me going. Also, if it doesn't find the spinlock code, it will report an error, so we should flesh this all out as we collect supported platforms, which we haven't started yet. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The problem with waiting for 7.5 is that we will have no error reporting
> when our non-spinlock code is being executed, and with Opteron/Itanium,
> it seems like a good time to get it working.
Well, as long as you're prepared to reduce the list of known supported
platforms to zero as of 7.4beta3, and issue a fresh call for port reports.
But it seems to me that this is mostly a cosmetic cleanup and therefore
not the kind of thing to be doing late in beta. Couldn't we do
something that affects only Opteron/Itanium and doesn't take a chance
on breaking everything else?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The problem with waiting for 7.5 is that we will have no error reporting > > when our non-spinlock code is being executed, and with Opteron/Itanium, > > it seems like a good time to get it working. > > Well, as long as you're prepared to reduce the list of known supported > platforms to zero as of 7.4beta3, and issue a fresh call for port reports. I haven't collected any known reports yet. That happens later, I thought, nearer to RC1. > But it seems to me that this is mostly a cosmetic cleanup and therefore > not the kind of thing to be doing late in beta. Couldn't we do > something that affects only Opteron/Itanium and doesn't take a chance > on breaking everything else? Yes, but to throw an error if spinlocks aren't found, we need this patch. We would have to test for Opteron in all the platforms that test for specific CPU's but don't test for opteron, and might support opterion/itanium, but even then, we don't have any way of getting a report of a failure. Yea, I should have thought of this before beta1, but now that I see the bug reports, seems we have to go this way. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thu, 11 Sep 2003, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The problem with waiting for 7.5 is that we will have no error reporting > > when our non-spinlock code is being executed, and with Opteron/Itanium, > > it seems like a good time to get it working. > > Well, as long as you're prepared to reduce the list of known supported > platforms to zero as of 7.4beta3, and issue a fresh call for port reports. I didn't think we had done that yet ... had we? called for port reports, that is ... ? > But it seems to me that this is mostly a cosmetic cleanup and therefore > not the kind of thing to be doing late in beta. Couldn't we do > something that affects only Opteron/Itanium and doesn't take a chance > on breaking everything else? I just went through the whole patch myself, and as much as I like the overall simplification, I tend to agree with Tom here on questioning the requirement to do suck a massive change so late in the end cycle ... is there no smaller bandaid that can be applied to handle the Opteron/Itanium issue for v7.4, with the "cleanup patch" being applied right away after v7.4?
Marc G. Fournier wrote:
> > But it seems to me that this is mostly a cosmetic cleanup and therefore
> > not the kind of thing to be doing late in beta. Couldn't we do
> > something that affects only Opteron/Itanium and doesn't take a chance
> > on breaking everything else?
>
> I just went through the whole patch myself, and as much as I like the
> overall simplification, I tend to agree with Tom here on questioning the
> requirement to do suck a massive change so late in the end cycle ... is
> there no smaller bandaid that can be applied to handle the Opteron/Itanium
> issue for v7.4, with the "cleanup patch" being applied right away after
> v7.4?
Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
I guess we could splatter a test for Itanium and Opterion in every port
that could possibly use it, but then again, if we fall back to not
finding it for some reason, we don't get a report because we silently
fall back to semaphores. That's what has me worried, that if we don't
do it, we will not know what platforms really aren't working properly.
Take FreeBSD for example, that couldn't find Opteron. It lists every
cpu like this:
#if defined(__i386__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#endif
#if defined(__sparc__)
#define NEED_SPARC_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#endif
We would have to add an opteron/itanium to port that does this, but if
we miss some opteron/itanium define, we might never know because of the
silent fallback.
I don't care if we save it for 7.5 --- I just don't know how we will be
sure we have things working properly without it.
We could apply it tomorrow and see how things look on Monday.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
--On Thursday, September 11, 2003 23:46:56 -0300 "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > > On Thu, 11 Sep 2003, Tom Lane wrote: > >> Bruce Momjian <pgman@candle.pha.pa.us> writes: >> > The problem with waiting for 7.5 is that we will have no error >> > reporting when our non-spinlock code is being executed, and with >> > Opteron/Itanium, it seems like a good time to get it working. >> >> Well, as long as you're prepared to reduce the list of known supported >> platforms to zero as of 7.4beta3, and issue a fresh call for port >> reports. > > I didn't think we had done that yet ... had we? called for port reports, > that is ... ? > >> But it seems to me that this is mostly a cosmetic cleanup and therefore >> not the kind of thing to be doing late in beta. Couldn't we do >> something that affects only Opteron/Itanium and doesn't take a chance >> on breaking everything else? > > I just went through the whole patch myself, and as much as I like the > overall simplification, I tend to agree with Tom here on questioning the > requirement to do suck a massive change so late in the end cycle ... is > there no smaller bandaid that can be applied to handle the Opteron/Itanium > issue for v7.4, with the "cleanup patch" being applied right away after > v7.4? > Bruce sent me a copy of the patch, and it ****BREAKS**** UnixWare (If y'all care). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Thu, 11 Sep 2003, Bruce Momjian wrote: > Yes, but to throw an error if spinlocks aren't found, we need this > patch. We would have to test for Opteron in all the platforms that test > for specific CPU's but don't test for opteron, and might support > opterion/itanium, but even then, we don't have any way of getting a > report of a failure. 'K, but apparently right now we are broken on Opteron/Itanium without this patch ... so, to fix, we either: a. add appropriate tests to the individual port files based on individual failure reports (albeit not clean, definitely safer), or: b. we do massive, sweeping changes to the whole HAVE_TEST_AND_SET detection code (definitely cleaner, but has potential of breaking more then it fixes) :( personally, as late in the cycle as we are, I think that a. is the wiser move for v7.4, with b. being something that should happen as soon as possible once we've branched and start working on v7.5 ...
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Thu, 11 Sep 2003, Tom Lane wrote:
>> Well, as long as you're prepared to reduce the list of known supported
>> platforms to zero as of 7.4beta3, and issue a fresh call for port reports.
> I didn't think we had done that yet ... had we? called for port reports,
> that is ... ?
We hadn't, no. My point is that in the past we've continued to list
platforms as supported if we've had a successful report in the past
release or two. Fooling with the spinlock code is delicate enough
that I'd want to insist on moving everything to the "unsupported"
category until we get a success report with the modified code.
Maybe we should just do that. It's likely that the only platforms
that end up marked unsupported are ones that no one cares about any
more anyway. But I think we have to realize that this is not a
trivial set of changes, even if it looks like it "should work".
(Which it does, just for the record. I'm just feeling paranoid
because of where we are in the release cycle.)
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I guess we could splatter a test for Itanium and Opterion in every port
> that could possibly use it, but then again, if we fall back to not
> finding it for some reason, we don't get a report because we silently
> fall back to semaphores. That's what has me worried, that if we don't
> do it, we will not know what platforms really aren't working properly.
Agreed, the silent fallback to semaphores isn't such a hot idea in
hindsight. But the part of the patch that requires a configure option
to use that code path could be applied without touching anything else.
regards, tom lane
Larry Rosenman <ler@lerctr.org> writes:
> Bruce sent me a copy of the patch, and it ****BREAKS**** UnixWare (If y'all=
> =20
> care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms that are actively being tested.
It's the stuff that hasn't been confirmed recently that is going to be
at risk.
regards, tom lane
Tom Lane wrote: > Larry Rosenman <ler@lerctr.org> writes: > > Bruce sent me a copy of the patch, and it ****BREAKS**** UnixWare (If y'all= > > =20 > > care). > > Unfixably? Or just a small oversight? > > I'm actually not worried about platforms that are actively being tested. > It's the stuff that hasn't been confirmed recently that is going to be > at risk. I sent him a new patch just now. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
--On Thursday, September 11, 2003 23:13:54 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> Bruce sent me a copy of the patch, and it ****BREAKS**** UnixWare (If >> y'all= =20 >> care). > > Unfixably? Or just a small oversight? > > I'm actually not worried about platforms that are actively being tested. > It's the stuff that hasn't been confirmed recently that is going to be > at risk. I'm seeing failures with the 2nd patch as well. Seems like it's not liking UnixWare's cc defines. the documentation is at: http://www.lerctr.org:8458/ the cc man page is at: http://www.lerctr.org:8458/en/man/html.1/cc.1.html Tom, You still have an account here. Bruce, if you'd like an account, that is easily arranged. LER > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I guess we could splatter a test for Itanium and Opterion in every port > > that could possibly use it, but then again, if we fall back to not > > finding it for some reason, we don't get a report because we silently > > fall back to semaphores. That's what has me worried, that if we don't > > do it, we will not know what platforms really aren't working properly. > > Agreed, the silent fallback to semaphores isn't such a hot idea in > hindsight. But the part of the patch that requires a configure option > to use that code path could be applied without touching anything else. Yes, we could do just the configure warning, then plaster tests into the port files to try to hit all the opteron/itanium cases. I am a little concerned that this might throw up a bunch of problem cases that we will patching for a while. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, we could do just the configure warning, then plaster tests into the
> port files to try to hit all the opteron/itanium cases. I am a little
> concerned that this might throw up a bunch of problem cases that we will
> patching for a while.
Probably so --- but we'd only be breaking new platforms that people are
starting to use, not old ones that might not be getting tested
regularly.
Understand that I'm not dead set against applying this patch for 7.4.
(On a code-cleanliness point of view I favor it.) What I want is some
open discussion about the risks and benefits before we decide.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Yes, we could do just the configure warning, then plaster tests into the > > port files to try to hit all the opteron/itanium cases. I am a little > > concerned that this might throw up a bunch of problem cases that we will > > patching for a while. > > Probably so --- but we'd only be breaking new platforms that people are > starting to use, not old ones that might not be getting tested > regularly. Looking at the code, I wonder if we already have folks not using spinlocks, and not even knowing it. I don't think problem reports will be limited to new platforms. > Understand that I'm not dead set against applying this patch for 7.4. > (On a code-cleanliness point of view I favor it.) What I want is some > open discussion about the risks and benefits before we decide. Sure, and I am not pushing the patch. I am just saying it would have been ideal a few weeks ago --- I am not sure if we are worse off with or without it. I just learned from Larry that Unixware defines intel as i386, not __i386 or __i386__, at least of the native SCO compiler that he uses. What the code used to do is define NEED_I386_TAS_ASM unconditionally on some platforms (negating the need to test for a compiler symbol) or test for each platform compiler symbol (and not test all possible ways it could be specified), like FreeBSD did. That's why things are so messy. I am going to test for __cpu, __cpu__, and cpu on non-gcc compiler for consistency. It is only done in one place in the patch, so that should be good. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Looking at the code, I wonder if we already have folks not using
> spinlocks, and not even knowing it. I don't think problem reports will
> be limited to new platforms.
Very likely --- I heard from someone recently who was trying to run
HPUX/Itanium. After we got past the hard-wired assumption that HPUX
== HPPA, it was still giving lousy performance for lack of spinlocks.
I like the part of the patch that is in-your-face about that.
> I just learned from Larry that Unixware defines intel as i386, not
> __i386 or __i386__, at least of the native SCO compiler that he uses.
[blink] Namespace infringement 'r us, huh?
> I am going to test for __cpu, __cpu__, and cpu on non-gcc compiler for
> consistency. It is only done in one place in the patch, so that should
> be good.
Please, only the first two. Make the Unixware template add __i386__.
Don't add assumptions about valid user-namespace symbols.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Looking at the code, I wonder if we already have folks not using > > spinlocks, and not even knowing it. I don't think problem reports will > > be limited to new platforms. > > Very likely --- I heard from someone recently who was trying to run > HPUX/Itanium. After we got past the hard-wired assumption that HPUX > == HPPA, it was still giving lousy performance for lack of spinlocks. > I like the part of the patch that is in-your-face about that. > > > I just learned from Larry that Unixware defines intel as i386, not > > __i386 or __i386__, at least of the native SCO compiler that he uses. > > [blink] Namespace infringement 'r us, huh? > > > I am going to test for __cpu, __cpu__, and cpu on non-gcc compiler for > > consistency. It is only done in one place in the patch, so that should > > be good. > > Please, only the first two. Make the Unixware template add __i386__. > Don't add assumptions about valid user-namespace symbols. Roger! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Looking at the code, I wonder if we already have folks not using >> spinlocks, and not even knowing it. I don't think problem reports will >> be limited to new platforms. > > Very likely --- I heard from someone recently who was trying to run > HPUX/Itanium. After we got past the hard-wired assumption that HPUX > == HPPA, it was still giving lousy performance for lack of spinlocks. > I like the part of the patch that is in-your-face about that. > >> I just learned from Larry that Unixware defines intel as i386, not >> __i386 or __i386__, at least of the native SCO compiler that he uses. > > [blink] Namespace infringement 'r us, huh? Yeah. I **DO** have SCO's ear on it, but I don't know how far I'll get, plus there are TONS of pre-whenever-we-get-it-fixed out there. > >> I am going to test for __cpu, __cpu__, and cpu on non-gcc compiler for >> consistency. It is only done in one place in the patch, so that should >> be good. > > Please, only the first two. Make the Unixware template add __i386__. > Don't add assumptions about valid user-namespace symbols. that's reasonable. At least until 64-bit UnixWare. :-) (announced at SCOForum). > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
>> Please, only the first two. Make the Unixware template add __i386__.
>> Don't add assumptions about valid user-namespace symbols.
> that's reasonable. At least until 64-bit UnixWare. :-)
Even then, I'd prefer to put the necessary kluge into template/unixware
or Makefile.unixware or port/unixware.h, rather than add a risky
assumption globally.
regards, tom lane
--On Friday, September 12, 2003 00:00:43 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >>> Please, only the first two. Make the Unixware template add __i386__. >>> Don't add assumptions about valid user-namespace symbols. > >> that's reasonable. At least until 64-bit UnixWare. :-) > > Even then, I'd prefer to put the necessary kluge into template/unixware > or Makefile.unixware or port/unixware.h, rather than add a risky > assumption globally. Sure, and 64-bit UnixWare is 2 years out any way. Hopefully we can get reasonableness by then. I've already sent a whine-a-gram to the compiler guys at SCO. LER > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
> I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be plenty easy compared
to getting them to *remove* the one for i386. And while I think
they should remove the latter, the immediate problem would be
solved as soon as they add the former.
regards, tom lane
On Thu, 11 Sep 2003, Bruce Momjian wrote: > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports. > I guess we could splatter a test for Itanium and Opterion in every port > that could possibly use it, but then again, if we fall back to not > finding it for some reason, we don't get a report because we silently > fall back to semaphores. That's what has me worried, that if we don't > do it, we will not know what platforms really aren't working properly. From what I understand, "not working properly" means slow, not broken, no? Which means ppl could submit a problem report and it could be fixed for v7.4.1 ... its not so much 'not working properly' as it is 'not optimal performance' ...
--On Friday, September 12, 2003 00:06:49 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> I've already sent a whine-a-gram to the compiler guys at SCO. > > Prolly you thought of this already, but: getting them to *add* > an implicit #define of __i386__ should be plenty easy compared > to getting them to *remove* the one for i386. And while I think > they should remove the latter, the immediate problem would be > solved as soon as they add the former. sure, and I expect that's what they may do. We'll see what they say. LER > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Marc G. Fournier wrote: > > > On Thu, 11 Sep 2003, Bruce Momjian wrote: > > > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports. > > I guess we could splatter a test for Itanium and Opterion in every port > > that could possibly use it, but then again, if we fall back to not > > finding it for some reason, we don't get a report because we silently > > fall back to semaphores. That's what has me worried, that if we don't > > do it, we will not know what platforms really aren't working properly. > > >From what I understand, "not working properly" means slow, not broken, no? > Which means ppl could submit a problem report and it could be fixed for > v7.4.1 ... its not so much 'not working properly' as it is 'not optimal > performance' ... Right, though I am not sure people will know _slow_ configuration vs. PostgreSQL is slow. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thu, 11 Sep 2003, Bruce Momjian wrote: > I just learned from Larry that Unixware defines intel as i386, not > __i386 or __i386__, at least of the native SCO compiler that he uses. could we put something in the various port files to standardize this? ie. in unixware.h, add somethinglike: #ifdef i386 #define __i386__ #endif just so that 'special cases' are centralized in the ports file, and the mainstream code doesn't have: #if defined(i386) || defined(__i386) || defined(__i386__) ?
Marc G. Fournier wrote: > > On Thu, 11 Sep 2003, Bruce Momjian wrote: > > > I just learned from Larry that Unixware defines intel as i386, not > > __i386 or __i386__, at least of the native SCO compiler that he uses. > > could we put something in the various port files to standardize this? ie. > in unixware.h, add somethinglike: > > #ifdef i386 > #define __i386__ > #endif > > just so that 'special cases' are centralized in the ports file, and the > mainstream code doesn't have: > > #if defined(i386) || defined(__i386) || defined(__i386__) Yep, that's what Tom wants and I am doing that now. I sent a patch to Larry for testing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Fri, 12 Sep 2003, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > > > > On Thu, 11 Sep 2003, Bruce Momjian wrote: > > > > > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports. > > > I guess we could splatter a test for Itanium and Opterion in every port > > > that could possibly use it, but then again, if we fall back to not > > > finding it for some reason, we don't get a report because we silently > > > fall back to semaphores. That's what has me worried, that if we don't > > > do it, we will not know what platforms really aren't working properly. > > > > >From what I understand, "not working properly" means slow, not broken, no? > > Which means ppl could submit a problem report and it could be fixed for > > v7.4.1 ... its not so much 'not working properly' as it is 'not optimal > > performance' ... > > Right, though I am not sure people will know _slow_ configuration vs. > PostgreSQL is slow. No, but definitely something for those discussion performance to add to their checklist :) BTW, post-compile, running system ... how do you check this? Or can you? For instance, having a checklist, of sorts, that ppl can go through when trying to investigate performance issues could include stuff like: check swap usage (albeit obvious to alot of ppl, not to all) check disk usage using iostat check spinlocks in use using ... ??
"Marc G. Fournier" <scrappy@postgresql.org> writes:
>> Right, though I am not sure people will know _slow_ configuration vs.
>> PostgreSQL is slow.
> No, but definitely something for those discussion performance to add
> to their checklist :)
> BTW, post-compile, running system ... how do you check this? Or can you?
If we force people to give a --without-spinlocks config option to build
that way, then `pg_config --configure' will reveal the dirty deed ...
regards, tom lane
Marc G. Fournier wrote: > > > >From what I understand, "not working properly" means slow, not broken, no? > > > Which means ppl could submit a problem report and it could be fixed for > > > v7.4.1 ... its not so much 'not working properly' as it is 'not optimal > > > performance' ... > > > > Right, though I am not sure people will know _slow_ configuration vs. > > PostgreSQL is slow. > > No, but definitely something for those discussion performance to add > to their checklist :) > > BTW, post-compile, running system ... how do you check this? Or can you? > > For instance, having a checklist, of sorts, that ppl can go through when > trying to investigate performance issues could include stuff like: > > check swap usage (albeit obvious to alot of ppl, not to all) > check disk usage using iostat > check spinlocks in use using ... ?? We can add the compiler test that will throw an error if they aren't using spinlocks, and they have to use a configure flag to enable it. The only issue there is that this is going to throw up perhaps many cases we haven't gotten working, and they might dribble out for weeks or after final, while a clean solution could break more platforms in the short term, but could catch more in the long term. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Larry Rosenman <ler@lerctr.org> writes: > > Bruce sent me a copy of the patch, and it ****BREAKS**** UnixWare (If y'all= > > =20 > > care). > > Unfixably? Or just a small oversight? Updated patch now works on Unixware. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Fri, 12 Sep 2003, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > >> Right, though I am not sure people will know _slow_ configuration vs. > >> PostgreSQL is slow. > > > No, but definitely something for those discussion performance to add > > to their checklist :) > > > BTW, post-compile, running system ... how do you check this? Or can you? > > If we force people to give a --without-spinlocks config option to build > that way, then `pg_config --configure' will reveal the dirty deed ... That's not quite what I meant :) Right now, if I understood what Bruce was saying, if someone doesn't have spinlocks, it switches to using SysV Messenging, correct? In the current system, is there anything that one can do on a running, live system, to detect that you aren't using spinlocks?
Marc G. Fournier wrote: > > > On Fri, 12 Sep 2003, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > >> Right, though I am not sure people will know _slow_ configuration vs. > > >> PostgreSQL is slow. > > > > > No, but definitely something for those discussion performance to add > > > to their checklist :) > > > > > BTW, post-compile, running system ... how do you check this? Or can you? > > > > If we force people to give a --without-spinlocks config option to build > > that way, then `pg_config --configure' will reveal the dirty deed ... > > That's not quite what I meant :) Right now, if I understood what Bruce > was saying, if someone doesn't have spinlocks, it switches to using SysV > Messenging, correct? In the current system, is there anything that one > can do on a running, live system, to detect that you aren't using > spinlocks? No. I don't think so. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Marc G. Fournier" <scrappy@postgresql.org> writes:
>> If we force people to give a --without-spinlocks config option to build
>> that way, then `pg_config --configure' will reveal the dirty deed ...
> That's not quite what I meant :) Right now, if I understood what Bruce
> was saying, if someone doesn't have spinlocks, it switches to using SysV
> Messenging, correct? In the current system, is there anything that one
> can do on a running, live system, to detect that you aren't using
> spinlocks?
It'll be fairly obvious if you use "ipcs -s" and count up the number of
semaphores created by the postmaster. Ordinarily we will grab
approximately max_connections semas, but without spinlocks it will
be somewhere north of max_connections + 2 * shared_buffers ...
regards, tom lane
On Fri, 12 Sep 2003, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > >> If we force people to give a --without-spinlocks config option to build > >> that way, then `pg_config --configure' will reveal the dirty deed ... > > > That's not quite what I meant :) Right now, if I understood what Bruce > > was saying, if someone doesn't have spinlocks, it switches to using SysV > > Messenging, correct? In the current system, is there anything that one > > can do on a running, live system, to detect that you aren't using > > spinlocks? > > It'll be fairly obvious if you use "ipcs -s" and count up the number of > semaphores created by the postmaster. Ordinarily we will grab > approximately max_connections semas, but without spinlocks it will > be somewhere north of max_connections + 2 * shared_buffers ... 'K, now, I know we acquire all our shared_buffers on startup now ... do we do the same with semaphores? Or do they only grow as connections grow? If we do acquire at the start, would it not be trivial to add a message to the startup messages, based on #_of_semaphores != max_connections, that tells ppl that spinlocks aren't being used?
Marc G. Fournier wrote: > > > On Fri, 12 Sep 2003, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > >> If we force people to give a --without-spinlocks config option to build > > >> that way, then `pg_config --configure' will reveal the dirty deed ... > > > > > That's not quite what I meant :) Right now, if I understood what Bruce > > > was saying, if someone doesn't have spinlocks, it switches to using SysV > > > Messenging, correct? In the current system, is there anything that one > > > can do on a running, live system, to detect that you aren't using > > > spinlocks? > > > > It'll be fairly obvious if you use "ipcs -s" and count up the number of > > semaphores created by the postmaster. Ordinarily we will grab > > approximately max_connections semas, but without spinlocks it will > > be somewhere north of max_connections + 2 * shared_buffers ... > > 'K, now, I know we acquire all our shared_buffers on startup now ... do we > do the same with semaphores? Or do they only grow as connections grow? > If we do acquire at the start, would it not be trivial to add a message to > the startup messages, based on #_of_semaphores != max_connections, that > tells ppl that spinlocks aren't being used? But why not warn at compile time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> do the same with semaphores?
Yes.
> If we do acquire at the start, would it not be trivial to add a message to
> the startup messages, based on #_of_semaphores != max_connections, that
> tells ppl that spinlocks aren't being used?
The code already knows whether it's compiled to use spinlocks or not, it
hardly needs to test that way ;-). I thought you were asking how to
double-check a system that's live today.
I prefer Bruce's idea of a configure-time warning, myself.
regards, tom lane
Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > 'K, now, I know we acquire all our shared_buffers on startup now ... do we > > do the same with semaphores? > > Yes. > > > If we do acquire at the start, would it not be trivial to add a message to > > the startup messages, based on #_of_semaphores != max_connections, that > > tells ppl that spinlocks aren't being used? > > The code already knows whether it's compiled to use spinlocks or not, it > hardly needs to test that way ;-). I thought you were asking how to > double-check a system that's live today. > > I prefer Bruce's idea of a configure-time warning, myself. I talked to Marc via IM and I think he now understand the configure error is best --- it is the most visible way to report the failure. He was worried about packagers missing the warning, but it is a fatal error and requires them to enable a flag, so it is pretty clear and anyone who packages such a binary will know what they are doing. He is uncomfortable with the port/*.h changes at this point, so it seems I am going to have to add Itanium/Opteron tests to most of those files. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> He is uncomfortable with the port/*.h changes at this point, so it seems
> I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that kind, and
then we can look to see how big and ugly it is compared to the other?
If the alternative is shown to be really messy, that would sway my
opinion, maybe Marc's too.
regards, tom lane
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > He is uncomfortable with the port/*.h changes at this point, so it seems
> > I am going to have to add Itanium/Opteron tests to most of those files.
>
> Why don't you try to put together a proposed patch of that kind, and
> then we can look to see how big and ugly it is compared to the other?
> If the alternative is shown to be really messy, that would sway my
> opinion, maybe Marc's too.
OK, here is an Opteron/Itanium patch that might work. I say "might"
because I don't have a lot of confidence in the current spinlock
detection code. There is an uncoupling between the definition of
HAS_TEST_AND_SET, the data type used by slock_t, and the assembler code.
For example, here is darwin.h:
#if defined(__ppc__)
#define HAS_TEST_AND_SET
#endif
#if defined(__ppc__)
typedef unsigned int slock_t;
#else
typedef unsigned char slock_t;
#endif
Does this say that Darwin on something other than PPC doesn't have
spinlocks? Is that going to hit a spinlock define, or fall through?
Also, look at NEED_I386_TAS_ASM: It is used only by SCO compilers,
though it is defined for all Intel platforms. The s_lock.h gcc test
already tests __i386__. It really doesn't do anything on non-SCO
compilers, and non-SCO compilers are better testing for i386 anyway.
Also, Solaris has just this:
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
How do they know what CPU is being used? Both Sparc and i386 use
"unsigned char", so I guess it is OK, but I think you can see what I
mean when I say I don't have a lot of confidence in what we have now.
Let me also add that some slock_t typedef's didn't match the assembly
code. For example, __alpha_ on netbsd.h had slock_t defined as
"unsigned long", while in linux.h it was "long int". I assumed the
alpha was the correct one, but clearly they should be the same because
they use the same assembly code.
See what I mean.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: src/include/port/bsdi.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/bsdi.h,v
retrieving revision 1.8
diff -c -c -r1.8 bsdi.h
*** src/include/port/bsdi.h 4 Aug 2003 00:43:32 -0000 1.8
--- src/include/port/bsdi.h 12 Sep 2003 15:14:15 -0000
***************
*** 1,10 ****
! #if defined(__i386__)
#define NEED_I386_TAS_ASM
#endif
#if defined(__sparc__)
#define NEED_SPARC_TAS_ASM
#endif
#define HAS_TEST_AND_SET
- typedef unsigned char slock_t;
--- 1,14 ----
! #if defined(__i386__) || defined(__x86_64__)
#define NEED_I386_TAS_ASM
+ typedef unsigned char slock_t;
+ #endif
+ #if defined(__ia64)
+ typedef unsigned int slock_t;
#endif
#if defined(__sparc__)
#define NEED_SPARC_TAS_ASM
+ typedef unsigned char slock_t;
#endif
#define HAS_TEST_AND_SET
Index: src/include/port/freebsd.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/freebsd.h,v
retrieving revision 1.10
diff -c -c -r1.10 freebsd.h
*** src/include/port/freebsd.h 4 Aug 2003 00:43:32 -0000 1.10
--- src/include/port/freebsd.h 12 Sep 2003 15:14:15 -0000
***************
*** 1,7 ****
! #if defined(__i386__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#endif
#if defined(__sparc__)
--- 1,12 ----
! #if defined(__i386__) || defined(__x86_64__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
+ #endif
+
+ #if defined(__ia64)
+ #define HAS_TEST_AND_SET
+ typedef unsigned int slock_t;
#endif
#if defined(__sparc__)
Index: src/include/port/netbsd.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/netbsd.h,v
retrieving revision 1.9
diff -c -c -r1.9 netbsd.h
*** src/include/port/netbsd.h 4 Aug 2003 00:43:32 -0000 1.9
--- src/include/port/netbsd.h 12 Sep 2003 15:14:15 -0000
***************
*** 1,7 ****
! #if defined(__i386__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#endif
#if defined(__sparc__)
--- 1,12 ----
! #if defined(__i386__) || defined(__x86_64__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
+ #endif
+
+ #if defined(__ia64)
+ #define HAS_TEST_AND_SET
+ typedef unsigned int slock_t;
#endif
#if defined(__sparc__)
Index: src/include/port/openbsd.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/openbsd.h,v
retrieving revision 1.8
diff -c -c -r1.8 openbsd.h
*** src/include/port/openbsd.h 4 Aug 2003 00:43:32 -0000 1.8
--- src/include/port/openbsd.h 12 Sep 2003 15:14:15 -0000
***************
*** 1,7 ****
! #if defined(__i386__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#endif
#if defined(__sparc__)
--- 1,12 ----
! #if defined(__i386__) || defined(__x86_64__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
+ #endif
+
+ #if defined(__ia64)
+ #define HAS_TEST_AND_SET
+ typedef unsigned int slock_t;
#endif
#if defined(__sparc__)
Index: src/include/port/sco.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/sco.h,v
retrieving revision 1.13
diff -c -c -r1.13 sco.h
*** src/include/port/sco.h 28 Oct 2001 06:26:08 -0000 1.13
--- src/include/port/sco.h 12 Sep 2003 15:14:15 -0000
***************
*** 6,12 ****
--- 6,18 ----
#define USE_UNIVEL_CC
+ #if defined(__ia64)
+ #define HAS_TEST_AND_SET
+ typedef unsigned int slock_t;
+ #else
typedef unsigned char slock_t;
+ #endif
+
#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
Index: src/include/port/univel.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/univel.h,v
retrieving revision 1.17
diff -c -c -r1.17 univel.h
*** src/include/port/univel.h 28 Oct 2001 06:26:08 -0000 1.17
--- src/include/port/univel.h 12 Sep 2003 15:14:15 -0000
***************
*** 7,13 ****
--- 7,18 ----
***************************************/
#define USE_UNIVEL_CC
+ #if defined(__ia64)
+ typedef unsigned int slock_t;
+ #else
typedef unsigned char slock_t;
+ #endif
+
#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
Index: src/include/port/unixware.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port/unixware.h,v
retrieving revision 1.11
diff -c -c -r1.11 unixware.h
*** src/include/port/unixware.h 28 Oct 2001 06:26:08 -0000 1.11
--- src/include/port/unixware.h 12 Sep 2003 15:14:15 -0000
***************
*** 10,16 ****
--- 10,21 ----
***************************************/
#define USE_UNIVEL_CC
+ #if defined(__ia64)
+ typedef unsigned int slock_t;
+ #else
typedef unsigned char slock_t;
+ #endif
+
#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Does this say that Darwin on something other than PPC doesn't have
> spinlocks? Is that going to hit a spinlock define, or fall through?
It says that darwin.h is broken, and always has been, for non-PPC
builds. Since there is no non-PPC Darwin (afaik), this is cosmetic.
Keep in mind that the argument here is exactly over whether we should
be fixing cosmetic issues right now.
> Also, look at NEED_I386_TAS_ASM: It is used only by SCO compilers,
> though it is defined for all Intel platforms. The s_lock.h gcc test
> already tests __i386__. It really doesn't do anything on non-SCO
> compilers, and non-SCO compilers are better testing for i386 anyway.
<shrug> Again, we were asking you what it would take to fix
Opteron/Itanium. Not to clean up cosmetic issues that have never caused
any problem before.
> Let me also add that some slock_t typedef's didn't match the assembly
> code. For example, __alpha_ on netbsd.h had slock_t defined as
> "unsigned long", while in linux.h it was "long int". I assumed the
> alpha was the correct one, but clearly they should be the same because
> they use the same assembly code.
As long as it's the right width, whether the code thinks it's signed or
not isn't gonna matter. We don't do any comparisons on spinlocks,
except maybe zero/notzero.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Does this say that Darwin on something other than PPC doesn't have > > spinlocks? Is that going to hit a spinlock define, or fall through? > > It says that darwin.h is broken, and always has been, for non-PPC > builds. Since there is no non-PPC Darwin (afaik), this is cosmetic. > Keep in mind that the argument here is exactly over whether we should > be fixing cosmetic issues right now. > > > Also, look at NEED_I386_TAS_ASM: It is used only by SCO compilers, > > though it is defined for all Intel platforms. The s_lock.h gcc test > > already tests __i386__. It really doesn't do anything on non-SCO > > compilers, and non-SCO compilers are better testing for i386 anyway. > > <shrug> Again, we were asking you what it would take to fix > Opteron/Itanium. Not to clean up cosmetic issues that have never caused > any problem before. > > > Let me also add that some slock_t typedef's didn't match the assembly > > code. For example, __alpha_ on netbsd.h had slock_t defined as > > "unsigned long", while in linux.h it was "long int". I assumed the > > alpha was the correct one, but clearly they should be the same because > > they use the same assembly code. > > As long as it's the right width, whether the code thinks it's signed or > not isn't gonna matter. We don't do any comparisons on spinlocks, > except maybe zero/notzero. My point is we don't know how many of these platforms are already using non-spinlock code, but we will find out in 7.4, and we should find out because those folks are getting poor performance. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, here is an Opteron/Itanium patch that might work.
[having now read both patches]
Assuming that this covers the issues (what other OSes might run on
64-bit machines within 7.4's lifespan?) I think there is little question
that this is the more conservative patch to use for 7.4. I like your
larger cleanup, but for 7.5.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, here is an Opteron/Itanium patch that might work. > > [having now read both patches] > > Assuming that this covers the issues (what other OSes might run on > 64-bit machines within 7.4's lifespan?) I think there is little question > that this is the more conservative patch to use for 7.4. I like your > larger cleanup, but for 7.5. OK, all I am saying is that I can't 100% stand behind the partial patch. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: >Tom Lane wrote: > > >>Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >> >>>He is uncomfortable with the port/*.h changes at this point, so it seems >>>I am going to have to add Itanium/Opteron tests to most of those files. >>> >>> >>Why don't you try to put together a proposed patch of that kind, and >>then we can look to see how big and ugly it is compared to the other? >>If the alternative is shown to be really messy, that would sway my >>opinion, maybe Marc's too. >> >> > >OK, here is an Opteron/Itanium patch that might work. I say "might" >because I don't have a lot of confidence in the current spinlock >detection code. There is an uncoupling between the definition of >HAS_TEST_AND_SET, the data type used by slock_t, and the assembler code. > > Is the Itanium tas implementation correct? I think it should be xchg4.aqv instead of just xchg4 - as far as I know a normal atomic exchange is is not a memory barrier on Itanium. At least the Linux kernel version contains "cmpxchg4.aqv". -- Manfred
Manfred Spraul wrote: > Is the Itanium tas implementation correct? I think it should be > xchg4.aqv instead of just xchg4 - as far as I know a normal atomic > exchange is is not a memory barrier on Itanium. At least the Linux > kernel version contains "cmpxchg4.aqv". Sorry for the noise, I'm wrong: Itanium automatically uses acquire semantics with xchg. See top of page 16 on http://h21007.www2.hp.com/dspp/files/unprotected/itanium/spinlocks.pdf -- Manfred
Manfred Spraul <manfred@colorfullife.com> writes:
> Is the Itanium tas implementation correct?
FWIW, this evening I did a few dozen iterations of "make check" parallel
regression tests on a 4-way Itanium box at Red Hat's Toronto office,
working from CVS-tip sources. No sign of problems. That's not a proof
of correctness, of course, but it does give me some confidence ...
regards, tom lane
On Fri, 12 Sep 2003, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > OK, here is an Opteron/Itanium patch that might work. > > > > [having now read both patches] > > > > Assuming that this covers the issues (what other OSes might run on > > 64-bit machines within 7.4's lifespan?) I think there is little question > > that this is the more conservative patch to use for 7.4. I like your > > larger cleanup, but for 7.5. > > OK, all I am saying is that I can't 100% stand behind the partial patch. S'alright, but the partial patch is better then what we have now, which is what we're after ...