Re: MySQL on T2000
I think you misunderstand the compiler option, which is fine, because it applies to Solaris. Because accessing unaligned memory raises a hardware error which forces a kernel context switch, you can mitigate the risk of this by assuming that any k-aligned object is actually only j-aligned, j < k, and perform k / j loads instead. This reduces performance compared to a full k-sized load, but it's better than nothing. You correctly understood this part -- HOWEVER, if you STILL get an unaligned load error, the kernel can transparently handle this for you if you opt-in. Most likely if you're developing new code, you will opt-out, because it's better to find performance issues like this while still developing, but if you inherit x86 code that does terrible things, then it may save developer time to just save "whatever, just emulate it". In such a case, you will generate a hardware trap, but the process will not get a SIGBUS -- the difference is subtle but important. Again, this is a feature of Solaris/SPARC -- using -xmemalign[n]i The point of my previous post was to show that the default Linux behavior (for me) was (in kernel mode) to simple emulate the load with multiple smaller loads. I wouldn't be surprised if there was a way to enable unaligned load fixups automatically in Linux -- probably a kernel option or runtime configuration. Short version -> Not getting SIGBUS is NOT proof that unaligned loads are not happening. Patrick On Fri, Jan 31, 2014 at 3:59 PM, brian m. carlson < sand...@crustytoothpaste.net> wrote: > On Fri, Jan 31, 2014 at 03:50:37PM -0600, Patrick Baggett wrote: > > Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign > [2] > > Okay, what's happening here is that someone is forcing the compiler to > generate multiple aligned loads for pointers that are not properly > aligned, so that an unaligned load doesn't happen. In the first case, > that's because the kernel has functions to mark where unaligned accesses > would otherwise occur. > > Regardless, if userland tries to perform an unaligned load, the process > will get a SIGBUS. > > -- > brian m. carlson / brian with sandals: Houston, Texas, US > +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only > OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 >
Re: MySQL on T2000
On Fri, Jan 31, 2014 at 03:50:37PM -0600, Patrick Baggett wrote: > Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign [2] Okay, what's happening here is that someone is forcing the compiler to generate multiple aligned loads for pointers that are not properly aligned, so that an unaligned load doesn't happen. In the first case, that's because the kernel has functions to mark where unaligned accesses would otherwise occur. Regardless, if userland tries to perform an unaligned load, the process will get a SIGBUS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: MySQL on T2000
Yes, it does [1], and so does Solaris using SunPro CC using -xmemalign [2] [1] http://lists.freedesktop.org/archives/nouveau/2013-March/012435.html [2] https://blogs.oracle.com/d/entry/the_meaning_of_xmemalign On Fri, Jan 31, 2014 at 3:39 PM, brian m. carlson < sand...@crustytoothpaste.net> wrote: > On Thu, Jan 30, 2014 at 10:24:13PM +1100, Stewart Smith wrote: > > What doesn't help is that unaligned memory accesses abound in the MySQL > > server (I once switched the GCC flags for generating code to handle > > unaligned access... urgh) > > It isn't clear to me what you mean by "handle unaligned access", since > unaligned access always causes a SIGBUS on SPARC. To my knowledge, > there is no option to fix up unaligned accesses in the kernel like there > is on Alpha and ARM, so they're always fatal. I'm pretty sure that > Oracle would have noticed if MySQL died frequently on SPARC. > > -- > brian m. carlson / brian with sandals: Houston, Texas, US > +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only > OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 >
Re: MySQL on T2000
On Thu, Jan 30, 2014 at 10:24:13PM +1100, Stewart Smith wrote: > What doesn't help is that unaligned memory accesses abound in the MySQL > server (I once switched the GCC flags for generating code to handle > unaligned access... urgh) It isn't clear to me what you mean by "handle unaligned access", since unaligned access always causes a SIGBUS on SPARC. To my knowledge, there is no option to fix up unaligned accesses in the kernel like there is on Alpha and ARM, so they're always fatal. I'm pretty sure that Oracle would have noticed if MySQL died frequently on SPARC. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: MySQL on T2000
Chris Lawrence writes: > I've done a good amount of fine tuning of the database, but I'm > finding any query of complexity taking sometimes as much as 30x longer > to execute than on same-era x86 hardware running Debian. MySQL query execution is single threaded (one query in one thread). The T2000 chips (and T1000 before it) have absolutely awful single threaded performance - they're all about concurrency, not single thread perf. So these are really not the machines to run complex single queries on. They're more suited to many small queries at once. What doesn't help is that unaligned memory accesses abound in the MySQL server (I once switched the GCC flags for generating code to handle unaligned access... urgh) 30x sounds a little high... but I wouldn't be surprised if you had said 10 or 20x. It'll also very much depend on MySQL version you're using. ASsuming current debian, 5.5 should be the best possible... -- Stewart Smith pgphHyPEpbRS6.pgp Description: PGP signature
