Skip to content

Few improvements related to CPU cache line size and padding #42

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

akopytov
Copy link

Re-submitting #37 after a minor fix to the relevant code.

Bug #79636: CACHE_LINE_SIZE should be 128 on AArch64
Bug #79637: Hard-coded cache line size
Bug #79638: Reconcile CACHE_LINE_SIZE with CPU_LEVEL1_DCACHE_LINESIZE
Bug #79652: Suspicious padding in srv_conc_t

- changed CPU_LEVEL1_DCACHE_LINESIZE to default to 128 bytes on POWER
  and AArch64 architectures in cases when no value could be detected
  by CMake using getconf

- changed pfs_global.h to assume CPU_LEVEL1_DCACHE_LINESIZE is always
  defined (and throw a compile-time error if it's not)

- changed CACHE_LINE_SIZE definition in ut0counter.h to be an alias of
  CPU_LEVEL1_DCACHE_LINESIZE

- changed a number of hard-coded 64-byte cache line size values in the
  InnoDB code

- fixed insufficient padding for srv_conc members in srv0conc.cc
@mysql-oca-bot
Copy link

Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment:
"I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it."
Thanks

@akopytov
Copy link
Author

I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

@mysql-oca-bot
Copy link

Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow
bug http://bugs.mysql.com/bug.php?id=79683 for updates.
Thanks

grooverdan added a commit to grooverdan/mariadb-server that referenced this pull request Apr 1, 2016
Inspired by Alexey Kopytov's pull request mysql/mysql-server#42
the PFS_ALIGNED is set to CPU_LEVEL1_DCACHE_LINESIZE if defined.

A more complete patch in MySQL-5.7:
mysql/mysql-server@0d55a07

Inspired by the complete patch the volatile global variables of the performance
schema have been quantified by PFS_ALIGNED.
grooverdan added a commit to grooverdan/mariadb-server that referenced this pull request Apr 1, 2016
Inspired by Alexey Kopytov's pull request mysql/mysql-server#42
the PFS_ALIGNED is set to CPU_LEVEL1_DCACHE_LINESIZE if defined.

A more complete patch in MySQL-5.7:
mysql/mysql-server@0d55a07

Inspired by the complete patch the volatile global variables of the performance
schema have been quantified by PFS_ALIGNED.
grooverdan added a commit to grooverdan/mariadb-server that referenced this pull request Jun 2, 2016
Inspired by Alexey Kopytov's pull request mysql/mysql-server#42
the PFS_ALIGNED is set to CPU_LEVEL1_DCACHE_LINESIZE if defined.

A more complete patch in MySQL-5.7:
mysql/mysql-server@0d55a07

Inspired by the complete patch the volatile global variables of the performance
schema have been quantified by PFS_ALIGNED.
gunnarku pushed a commit to facebook/mysql-8.0 that referenced this pull request Jul 21, 2017
…n family

Summary:
Fix issue mysql#42. Also issue mysql#43: Ranges on t.key > const are not handled
efficiently:

Make ha_rocksdb::index_read_map() do the right thing when invoked with
find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column
families.

Detailed explanation of actions is provided in rocksdb-range-access.txt

Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered

Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim

Reviewed By: yoshinorim

Differential Revision: https://reviews.facebook.net/D35103
gunnarku pushed a commit to facebook/mysql-8.0 that referenced this pull request Jul 25, 2017
…n family

Summary:
Fix issue mysql#42. Also issue mysql#43: Ranges on t.key > const are not handled
efficiently:

Make ha_rocksdb::index_read_map() do the right thing when invoked with
find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column
families.

Detailed explanation of actions is provided in rocksdb-range-access.txt

Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered

Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim

Reviewed By: yoshinorim

Differential Revision: https://reviews.facebook.net/D35103
vmg pushed a commit to planetscale/mysql-server that referenced this pull request Nov 21, 2023
Support RENAME TABLE...PRESERVE FOREIGN KEY
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants