ການ​ແປ​ບົດ​ຄວາມ​ທີ່​ໄດ້​ກະ​ກຽມ​ສໍາ​ລັບ​ນັກ​ຮຽນ​ຫຼັກ​ສູດ​ "ຜູ້ເບິ່ງແຍງລະບົບ Linux".

ກ່ອນຫນ້ານີ້, ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບວິທີການທົດສອບແລະເປີດໃຊ້ Hugepages ໃນ Linux.
ບົດຄວາມນີ້ຈະເປັນປະໂຫຍດພຽງແຕ່ຖ້າຫາກວ່າທ່ານຕົວຈິງແລ້ວມີສະຖານທີ່ທີ່ຈະນໍາໃຊ້ Hugepages. ຂ້າພະເຈົ້າໄດ້ພົບກັບຫຼາຍໆຄົນທີ່ຖືກຫລອກລວງໂດຍຄວາມສົດໃສດ້ານທີ່ Hugepages ຈະປັບປຸງຜົນຜະລິດຢ່າງມະຫັດສະຈັນ. ຢ່າງໃດກໍຕາມ, hugepaging ເປັນຫົວຂໍ້ທີ່ສັບສົນແລະສາມາດຫຼຸດລົງປະສິດທິພາບຖ້າຫາກວ່າຖືກນໍາໃຊ້ບໍ່ຖືກຕ້ອງ.

ສ່ວນທີ 1: ການກວດສອບວ່າໜ້າໃຫຍ່ຖືກເປີດໃຊ້ໃນ Linux (ຕົ້ນສະບັບ ທີ່ນີ້)

ບັນຫາ:
ທ່ານຈໍາເປັນຕ້ອງກວດເບິ່ງວ່າ HugePages ຖືກເປີດໃຊ້ຢູ່ໃນລະບົບຂອງທ່ານ.

ການແກ້ໄຂ:
ມັນງ່າຍດາຍຫຼາຍ:

cat /sys/kernel/mm/transparent_hugepage/enabled

ທ່ານຈະໄດ້ຮັບບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

always [madvise] never

ທ່ານຈະເຫັນລາຍການທາງເລືອກທີ່ມີ (ສະເຫມີ, madvise, ບໍ່ເຄີຍ), ແລະທາງເລືອກທີ່ໃຊ້ໃນປັດຈຸບັນຈະຖືກຫຸ້ມຢູ່ໃນວົງເລັບ (ໂດຍຄ່າເລີ່ມຕົ້ນ Madvise).

Madvise ໝາຍ ຄວາມວ່າ transparent hugepages ເປີດໃຊ້ພຽງແຕ່ສໍາລັບພື້ນທີ່ຫນ່ວຍຄວາມຈໍາທີ່ຊັດເຈນຮ້ອງຂໍໃຫ້ມີຫນ້າຂະຫນາດໃຫຍ່ໂດຍໃຊ້ Madvise(2).

ສະເຫມີໄປ ໝາຍ ຄວາມວ່າ transparent hugepages ເປີດໃຊ້ງານສະເໝີສໍາລັບຂະບວນການທັງໝົດ. ນີ້ປົກກະຕິແລ້ວປັບປຸງປະສິດທິພາບ, ແຕ່ຖ້າຫາກວ່າທ່ານມີກໍລະນີການນໍາໃຊ້ທີ່ຂະບວນການຈໍານວນຫຼາຍກໍາລັງບໍລິໂພກຈໍານວນຂະຫນາດນ້ອຍຂອງຫນ່ວຍຄວາມຈໍາ, ຫຼັງຈາກນັ້ນການໂຫຼດຫນ່ວຍຄວາມຈໍາໂດຍລວມສາມາດເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ບໍ່ເຄີຍ ໝາຍ ຄວາມວ່າ transparent hugepages ຈະບໍ່ຖືກລວມເຂົ້າເຖິງແມ່ນວ່າຈະຖືກຮ້ອງຂໍໂດຍໃຊ້ madvise. ເພື່ອຊອກຫາຂໍ້ມູນເພີ່ມເຕີມ, ຕິດຕໍ່ ເອກະສານ Linux kernels.

ວິທີການປ່ຽນຄ່າເລີ່ມຕົ້ນ

Option 1: ປ່ຽນແປງໂດຍກົງ sysfs (ຫຼັງຈາກ reboot ຕົວກໍານົດການຈະກັບຄືນໄປຄ່າເລີ່ມຕົ້ນຂອງມັນ):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

Option 2: ປ່ຽນຄ່າເລີ່ມຕົ້ນຂອງລະບົບໂດຍການລວບລວມ kernel ຄືນໃໝ່ດ້ວຍການຕັ້ງຄ່າທີ່ປ່ຽນແປງ (ຕົວເລືອກນີ້ຖືກແນະນຳພຽງແຕ່ຖ້າເຈົ້າກຳລັງໃຊ້ kernel ແບບກຳນົດເອງ):

• ເພື່ອຕັ້ງເປັນຄ່າເລີ່ມຕົ້ນສະເໝີ, ໃຫ້ໃຊ້:

  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

• ເພື່ອຕັ້ງ madvise ເປັນຄ່າເລີ່ມຕົ້ນ, ໃຫ້ໃຊ້:

  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

ສ່ວນທີ 2: ຂໍ້ດີແລະຂໍ້ເສຍຂອງ HugePages

ພວກເຮົາຈະພະຍາຍາມອະທິບາຍຂໍ້ດີ, ຂໍ້ເສຍ ແລະ ໄພອັນຕະລາຍທີ່ເປັນໄປໄດ້ຂອງການໃຊ້ Hugepages. ນັບຕັ້ງແຕ່ບົດຄວາມທີ່ສັບສົນທາງດ້ານເຕັກໂນໂລຢີແລະ pedantic ອາດຈະຍາກທີ່ຈະເຂົ້າໃຈສໍາລັບຜູ້ທີ່ຖືກຫຼອກລວງໃນຄວາມຄິດຂອງ Hugepages ແມ່ນ panacea, ຂ້າພະເຈົ້າຈະເສຍສະລະຄວາມຖືກຕ້ອງເພື່ອຄວາມງ່າຍດາຍ. ມັນເປັນມູນຄ່າທີ່ຈື່ໄວ້ວ່າຫຼາຍຫົວຂໍ້ແມ່ນສັບສົນແທ້ໆແລະດັ່ງນັ້ນຈຶ່ງງ່າຍດາຍຫຼາຍ.

ກະລຸນາສັງເກດວ່າພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບລະບົບ 64-bit x86 ທີ່ໃຊ້ Linux, ແລະຂ້ອຍພຽງແຕ່ສົມມຸດວ່າລະບົບສະຫນັບສະຫນູນຂະຫນາດໃຫຍ່ທີ່ໂປ່ງໃສ (ເນື່ອງຈາກວ່າມັນບໍ່ແມ່ນຂໍ້ເສຍທີ່ hugepages ບໍ່ໄດ້ຖືກຂຽນທັບ), ເຊັ່ນດຽວກັນກັບເກືອບທຸກ Linux ທີ່ທັນສະໄຫມ. ສະພາບແວດລ້ອມ.

ຂ້າພະເຈົ້າຈະຄັດຕິດຄໍາອະທິບາຍດ້ານວິຊາການເພີ່ມເຕີມໃນການເຊື່ອມຕໍ່ຂ້າງລຸ່ມນີ້.

ໜ່ວຍຄວາມຈຳສະເໝືອນ

ຖ້າທ່ານເປັນໂປລແກລມ C++, ທ່ານຮູ້ວ່າວັດຖຸໃນຫນ່ວຍຄວາມຈໍາມີທີ່ຢູ່ສະເພາະ (ຄ່າຕົວຊີ້).

ຢ່າງໃດກໍຕາມ, ທີ່ຢູ່ເຫຼົ່ານີ້ບໍ່ຈໍາເປັນຕ້ອງສະທ້ອນເຖິງທີ່ຢູ່ທາງດ້ານຮ່າງກາຍໃນຫນ່ວຍຄວາມຈໍາ (ທີ່ຢູ່ RAM). ພວກເຂົາເປັນຕົວແທນທີ່ຢູ່ໃນຫນ່ວຍຄວາມຈໍາ virtual. ໂປເຊດເຊີມີໂມດູນ MMU ພິເສດ (ຫນ່ວຍການຄຸ້ມຄອງຫນ່ວຍຄວາມຈໍາ) ທີ່ຊ່ວຍໃຫ້ kernel ແຜນທີ່ຫນ່ວຍຄວາມຈໍາ virtual ກັບສະຖານທີ່ທາງດ້ານຮ່າງກາຍ.

ວິທີການນີ້ມີຂໍ້ດີຫຼາຍ, ແຕ່ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນ:

• ການປະຕິບັດ (ສໍາລັບເຫດຜົນຕ່າງໆ);
• ການແຍກໂຄງການ, ນັ້ນແມ່ນ, ບໍ່ມີໂປລແກລມໃດສາມາດອ່ານຈາກຄວາມຊົງຈໍາຂອງໂປແກຼມອື່ນ.

ໜ້າແມ່ນຫຍັງ?

ຫນ່ວຍຄວາມຈໍາ virtual ແບ່ງອອກເປັນຫນ້າ. ແຕ່ລະຫນ້າຊີ້ໃຫ້ເຫັນເຖິງຄວາມຊົງຈໍາທາງດ້ານຮ່າງກາຍສະເພາະ, ມັນສາມາດຊີ້ໄປຫາພື້ນທີ່ໃນ RAM, ຫຼືມັນສາມາດຊີ້ໄປຫາທີ່ຢູ່ທີ່ຖືກມອບຫມາຍໃຫ້ກັບອຸປະກອນທາງດ້ານຮ່າງກາຍເຊັ່ນບັດວີດີໂອ.

ຫນ້າສ່ວນໃຫຍ່ທີ່ທ່ານຈັດການກັບຈຸດທີ່ RAM ຫຼືຖືກປ່ຽນ, ຊຶ່ງຫມາຍຄວາມວ່າພວກມັນຖືກເກັບໄວ້ໃນຮາດໄດຫຼື SSD ຂອງທ່ານ. kernel ຈັດການຮູບແບບທາງດ້ານຮ່າງກາຍຂອງແຕ່ລະຫນ້າ. ຖ້າຫນ້າ spoofed ຖືກເຂົ້າເຖິງ, kernel ຈະຢຸດ thread ທີ່ພະຍາຍາມເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາ, ອ່ານຫນ້າຈາກຮາດໄດ / SSD ເຂົ້າໄປໃນ RAM, ແລະຫຼັງຈາກນັ້ນສືບຕໍ່ດໍາເນີນການ thread.

ຂະບວນການນີ້ແມ່ນໂປ່ງໃສ, ຊຶ່ງຫມາຍຄວາມວ່າມັນບໍ່ຈໍາເປັນຕ້ອງອ່ານໂດຍກົງຈາກ HDD / SSD. ຂະຫນາດຂອງຫນ້າປົກກະຕິແມ່ນ 4096 bytes. ຂະໜາດໜ້າໃຫຍ່ແມ່ນ 2 megabytes.

Translation-associative buffer (TLB)

ເມື່ອໂຄງການເຂົ້າເຖິງຫນ້າຂອງຫນ່ວຍຄວາມຈໍາ, CPU ຕ້ອງຮູ້ວ່າຫນ້າທາງດ້ານຮ່າງກາຍທີ່ຈະອ່ານຂໍ້ມູນຈາກ (ນັ້ນແມ່ນ, ມີແຜນທີ່ທີ່ຢູ່ virtual).

kernel ມີໂຄງສ້າງຂໍ້ມູນ (ຕາຕະລາງຫນ້າ) ທີ່ມີຂໍ້ມູນທັງຫມົດກ່ຽວກັບຫນ້າທີ່ຖືກນໍາໃຊ້. ການນໍາໃຊ້ໂຄງສ້າງຂໍ້ມູນນີ້, ທ່ານສາມາດແຜນທີ່ທີ່ຢູ່ virtual ກັບທີ່ຢູ່ທາງດ້ານຮ່າງກາຍ.

ຢ່າງໃດກໍຕາມ, ຕາຕະລາງຫນ້າແມ່ນຂ້ອນຂ້າງສັບສົນແລະຊ້າ, ດັ່ງນັ້ນພວກເຮົາບໍ່ສາມາດວິເຄາະໂຄງສ້າງຂໍ້ມູນທັງຫມົດທຸກຄັ້ງທີ່ຂະບວນການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາ.

ໂຊກດີ, ໂປເຊດເຊີຂອງພວກເຮົາມີ TLB ທີ່ເກັບຂໍ້ມູນແຜນທີ່ລະຫວ່າງທີ່ຢູ່ virtual ແລະທາງດ້ານຮ່າງກາຍ. ນີ້ຫມາຍຄວາມວ່າເຖິງແມ່ນວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ແຍກຕາຕະລາງຫນ້າໃນຄວາມພະຍາຍາມໃນການເຂົ້າເຖິງຄັ້ງທໍາອິດ, ທຸກໆການເຂົ້າເຖິງຕໍ່ໄປໃນຫນ້າສາມາດຖືກຈັດການຢູ່ໃນ TLB, ອະນຸຍາດໃຫ້ດໍາເນີນການໄດ້ໄວ.

ເນື່ອງຈາກວ່າມັນຖືກປະຕິບັດເປັນອຸປະກອນທາງດ້ານຮ່າງກາຍ (ເຊິ່ງເຮັດໃຫ້ມັນໄວໃນສະຖານທີ່ທໍາອິດ), ຄວາມສາມາດຂອງມັນແມ່ນຈໍາກັດ. ດັ່ງນັ້ນຖ້າທ່ານຕ້ອງການເຂົ້າຫາຫນ້າຫຼາຍ, TLB ຈະບໍ່ສາມາດເກັບຮັກສາແຜນທີ່ສໍາລັບພວກມັນທັງຫມົດ, ເຊິ່ງເຮັດໃຫ້ໂປຼແກຼມຂອງທ່ານເຮັດວຽກຊ້າລົງຫຼາຍ.

Hugepages ມາກູ້ໄພ

ດັ່ງນັ້ນພວກເຮົາສາມາດເຮັດແນວໃດເພື່ອຫຼີກເວັ້ນການ overflow TLB? (ພວກເຮົາສົມມຸດວ່າໂຄງການຍັງຕ້ອງການຈໍານວນຫນ່ວຍຄວາມຈໍາດຽວກັນ).

ນີ້ແມ່ນບ່ອນທີ່ Hugepages ເຂົ້າມາ. ແທນທີ່ຈະເປັນ 4096 bytes ທີ່ຕ້ອງການພຽງແຕ່ຫນຶ່ງ TLB entry, ຫນຶ່ງ TLB entry ປະຈຸບັນສາມາດຊີ້ໃຫ້ເຫັນເຖິງ 2 megabytes ທີ່ຍິ່ງໃຫຍ່. ໃຫ້ສົມມຸດວ່າ TLB ມີ 512 ລາຍການ, ທີ່ນີ້ໂດຍບໍ່ມີການ Hugepages ພວກເຮົາສາມາດຈັບຄູ່ໄດ້:

4096 b⋅512=2 MB

ແລ້ວພວກເຮົາຈະປຽບທຽບກັບເຂົາເຈົ້າໄດ້ແນວໃດ:

2 MB⋅512=1 GB

ນີ້ແມ່ນເຫດຜົນທີ່ວ່າ Hugepages ແມ່ນຫນ້າຫວາດສຽວ. ພວກເຂົາສາມາດປັບປຸງຜົນຜະລິດໄດ້ໂດຍບໍ່ຕ້ອງໃຊ້ຄວາມພະຍາຍາມຫຼາຍ. ແຕ່ມີຂໍ້ຄວນລະວັງທີ່ສໍາຄັນຢູ່ທີ່ນີ້.

ການຫຼອກລວງໜ້າໃຫຍ່

kernel ຕິດຕາມອັດຕະໂນມັດວ່າແຕ່ລະຫນ້າຫນ່ວຍຄວາມຈໍາຖືກນໍາໃຊ້ເລື້ອຍໆສໍ່າໃດ. ຖ້າບໍ່ມີຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍ (RAM) ພຽງພໍ, ແກ່ນຈະຍ້າຍຫນ້າທີ່ສໍາຄັນຫນ້ອຍ (ຫນ້ອຍທີ່ໃຊ້ເລື້ອຍໆ) ໄປຫາຮາດດິດເພື່ອຂະຫຍາຍ RAM ບາງຫນ້າສໍາລັບຫນ້າທີ່ສໍາຄັນກວ່າ.
ໃນຫຼັກການ, ດຽວກັນໃຊ້ກັບ Hugepages. ຢ່າງໃດກໍຕາມ, kernel ພຽງແຕ່ສາມາດແລກປ່ຽນຫນ້າທັງຫມົດ, ບໍ່ແມ່ນ bytes ສ່ວນບຸກຄົນ.

ສົມມຸດວ່າພວກເຮົາມີໂຄງການນີ້:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]); 

ໃນ​ກໍ​ລະ​ນີ​ນີ້​, kernel ຈະ​ຈໍາ​ເປັນ​ຕ້ອງ​ທົດ​ແທນ (ອ່ານ​) ເປັນ 2 megabytes ຂອງ​ຂໍ້​ມູນ​ຈາກ​ຮາດ​ດິດ / SSD ພຽງ​ແຕ່​ສໍາ​ລັບ​ທ່ານ​ທີ່​ຈະ​ອ່ານ​ຫນຶ່ງ byte​. ສໍາລັບຫນ້າປົກກະຕິ, ພຽງແຕ່ 4096 bytes ຕ້ອງໄດ້ຮັບການອ່ານຈາກຮາດໄດ / SSD.

ດັ່ງນັ້ນ, ຖ້າຫນ້າໃຫຍ່ຖືກ overridden, ມັນພຽງແຕ່ໄວກວ່າທີ່ຈະອ່ານຖ້າທ່ານຕ້ອງການເຂົ້າເຖິງຫນ້າທັງຫມົດ. ນີ້ຫມາຍຄວາມວ່າຖ້າທ່ານພະຍາຍາມເຂົ້າໄປຫາສ່ວນຕ່າງໆຂອງຫນ່ວຍຄວາມຈໍາແບບສຸ່ມແລະພຽງແຕ່ອ່ານສອງສາມກິໂລໄບ, ທ່ານຄວນໃຊ້ຫນ້າປົກກະຕິແລະບໍ່ກັງວົນກ່ຽວກັບສິ່ງອື່ນ.

ໃນທາງກົງກັນຂ້າມ, ຖ້າທ່ານຕ້ອງການເຂົ້າເຖິງສ່ວນໃຫຍ່ຂອງຫນ່ວຍຄວາມຈໍາຕາມລໍາດັບ, ຫນ້າໃຫຍ່ຈະປັບປຸງການປະຕິບັດຂອງທ່ານ. ຢ່າງໃດກໍຕາມ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ທົດສອບຕົວທ່ານເອງ (ບໍ່ແມ່ນກັບຊອບແວ abstract) ແລະເບິ່ງສິ່ງທີ່ເຮັດວຽກໄດ້ໄວຂຶ້ນ.

ການຈັດສັນໃນຄວາມຊົງຈໍາ

ຖ້າທ່ານຂຽນ C, ທ່ານຮູ້ວ່າທ່ານສາມາດຮ້ອງຂໍໃຫ້ມີຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ມີຂະຫນາດນ້ອຍ (ຫຼືເກືອບຂະຫນາດໃຫຍ່) ຈາກ heap ໂດຍໃຊ້ malloc(). ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການ 30 bytes ຂອງຫນ່ວຍຄວາມຈໍາ:

char* mymemory = malloc(30);

ສໍາລັບນັກຂຽນໂປລແກລມ, ມັນອາດຈະປາກົດວ່າທ່ານກໍາລັງ "ຮ້ອງຂໍ" ຫນ່ວຍຄວາມຈໍາ 30 bytes ຈາກລະບົບປະຕິບັດການແລະສົ່ງຕົວຊີ້ໄປຫາຫນ່ວຍຄວາມຈໍາ virtual. ແຕ່ຕົວຈິງແລ້ວ malloc () ແມ່ນພຽງແຕ່ຟັງຊັນ C ທີ່ໂທຫາຈາກພາຍໃນຟັງຊັນ brk ແລະ sbrk ເພື່ອຮ້ອງຂໍຫຼືຄວາມຊົງຈໍາທີ່ບໍ່ເສຍຄ່າຈາກລະບົບປະຕິບັດການ.

ຢ່າງໃດກໍ່ຕາມ, ການຮ້ອງຂໍຄວາມຊົງຈໍາຫຼາຍຂື້ນສໍາລັບການຈັດສັນແຕ່ລະຄົນແມ່ນບໍ່ມີປະສິດທິພາບ; ມັນເປັນໄປໄດ້ຫຼາຍທີ່ສຸດວ່າບາງສ່ວນຄວາມຊົງຈໍາໄດ້ຖືກປົດປ່ອຍແລ້ວ (free()), ແລະ​ພວກ​ເຮົາ​ສາ​ມາດ​ນໍາ​ໃຊ້​ຄືນ​ໄດ້​. malloc() ປະຕິບັດ algorithms ທີ່ຂ້ອນຂ້າງສັບສົນສໍາລັບການນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາທີ່ຖືກປົດປ່ອຍຄືນ.

ໃນເວລາດຽວກັນ, ທຸກສິ່ງທຸກຢ່າງເກີດຂື້ນໂດຍບໍ່ໄດ້ສັງເກດເຫັນສໍາລັບທ່ານ, ດັ່ງນັ້ນເປັນຫຍັງມັນຄວນກັງວົນທ່ານ? ແຕ່ເນື່ອງຈາກວ່າສິ່ງທ້າທາຍ free() ບໍ່ໄດ້ຫມາຍຄວາມວ່າ ຫນ່ວຍຄວາມຈໍາແມ່ນຈໍາເປັນກັບຄືນທັນທີກັບລະບົບປະຕິບັດການ.

ມີ​ສິ່ງ​ດັ່ງ​ກ່າວ​ເປັນ​ການ​ແບ່ງ​ແຍກ​ຄວາມ​ຊົງ​ຈໍາ​. ໃນກໍລະນີທີ່ຮ້າຍແຮງ, ມີພາກສ່ວນ heap ທີ່ມີພຽງແຕ່ສອງສາມ bytes ເທົ່ານັ້ນທີ່ຖືກນໍາໃຊ້ໃນຂະນະທີ່ທຸກສິ່ງທຸກຢ່າງຢູ່ໃນລະຫວ່າງໄດ້ຖືກປົດປ່ອຍ. (free()).

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ fragmentation ຄວາມ​ຊົງ​ຈໍາ​ເປັນ​ຫົວ​ຂໍ້​ທີ່​ຊັບ​ຊ້ອນ​ຢ່າງ​ບໍ່​ຫນ້າ​ເຊື່ອ​, ແລະ​ເຖິງ​ແມ່ນ​ວ່າ​ການ​ປ່ຽນ​ແປງ​ເລັກ​ນ້ອຍ​ຂອງ​ໂຄງ​ການ​ສາ​ມາດ​ມີ​ຜົນ​ກະ​ທົບ​ທີ່​ສໍາ​ຄັນ​. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ໂປລແກລມຈະບໍ່ເຮັດໃຫ້ເກີດການແບ່ງສ່ວນຫນ່ວຍຄວາມຈໍາທີ່ສໍາຄັນ, ແຕ່ທ່ານຄວນຮູ້ວ່າຖ້າມີບັນຫາການແຕກແຍກຢູ່ໃນບາງພື້ນທີ່ຂອງ heap, hugepages ສາມາດເຮັດໃຫ້ສະຖານະການຮ້າຍແຮງຂຶ້ນ.

ການ​ຄັດ​ເລືອກ​ການ​ນໍາ​ໃຊ້​ຂອງ hugepages​

ຫຼັງຈາກອ່ານບົດຄວາມນີ້, ທ່ານໄດ້ກໍານົດວ່າພາກສ່ວນໃດຂອງໂຄງການຂອງທ່ານສາມາດໄດ້ຮັບຜົນປະໂຫຍດຈາກການນໍາໃຊ້ hugepages ແລະສິ່ງທີ່ບໍ່ສາມາດ. ດັ່ງນັ້ນຫນ້າຂະຫນາດໃຫຍ່ຄວນຈະຖືກເປີດໃຊ້ທັງຫມົດບໍ?

ໂຊກດີທີ່ທ່ານສາມາດນໍາໃຊ້ madvise()ເພື່ອເປີດໃຊ້ງານໃຫຍ່ພຽງແຕ່ສໍາລັບພື້ນທີ່ຄວາມຊົງຈໍາທີ່ມັນຈະເປັນປະໂຫຍດ.

ທໍາອິດ, ໃຫ້ກວດເບິ່ງວ່າ hugepages ກໍາລັງແລ່ນຢູ່ໃນໂຫມດ madvise() ໂດຍໃຊ້ ຄໍາແນະນໍາ ໃນຕອນຕົ້ນຂອງບົດຄວາມ.

ຫຼັງຈາກນັ້ນ, ໃຊ້ madvise()ເພື່ອບອກ kernel ຢ່າງແທ້ຈິງບ່ອນທີ່ຈະໃຊ້ hugepages.

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

ໃຫ້ສັງເກດວ່າວິທີການນີ້ແມ່ນຄໍາແນະນໍາພຽງແຕ່ກັບແກ່ນກ່ຽວກັບວິທີການຈັດການຫນ່ວຍຄວາມຈໍາ. ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າ kernel ຈະນໍາໃຊ້ hugepages ອັດຕະໂນມັດສໍາລັບຫນ່ວຍຄວາມຈໍາທີ່ກໍານົດໄວ້.

ອ້າງເຖິງເອກະສານ (manpage)madviseເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບການຄຸ້ມຄອງຄວາມຊົງຈໍາແລະ madvise(), ຫົວຂໍ້ນີ້ມີເສັ້ນໂຄ້ງການຮຽນຮູ້ທີ່ສູງຊັນຢ່າງບໍ່ໜ້າເຊື່ອ. ສະນັ້ນ, ຖ້າເຈົ້າຕັ້ງໃຈຈະເກັ່ງແທ້ໆ, ກຽມອ່ານ ແລະ ທົດສອບສອງສາມອາທິດກ່ອນເຈົ້າຈະຄາດຫວັງຜົນໄດ້ຮັບໃນທາງບວກ.

ອ່ານຫຍັງ?

• ບົດຄວາມ IBM OpenStack ຢູ່ໃນຫນ້າໃຫຍ່
• ໜ້າໃຫຍ່ທີ່ໂປ່ງໃສທຽບກັບໜ້າໃຫຍ່ທີ່ບໍ່ໂປ່ງໃສ
• ບົດຄວາມ Wikipedia ກ່ຽວກັບ TLB
• ເອກະສານຂອງ Linux kernel ໃນຫນ້າຂະຫນາດໃຫຍ່ທີ່ໂປ່ງໃສ
• StackOverflow: Hugepages ມີຄວາມສ່ຽງຕໍ່ການແຕກແຍກຂອງຫນ່ວຍຄວາມຈໍາ
• ບົດຄວາມ Microsoft ກ່ຽວກັບການຈັດການຫນ່ວຍຄວາມຈໍາ virtual

ມີຄຳຖາມບໍ? ຂຽນໃນຄໍາເຫັນ!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com