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

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

ພາກທີ 1: ກວດສອບວ່າ hugepages ຖືກເປີດໃຊ້ງານແລ້ວ 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.

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

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, ຂ້າພະເຈົ້າຈະເສຍສະລະຄວາມຖືກຕ້ອງເພື່ອຄວາມງ່າຍດາຍ. ມັນເປັນມູນຄ່າທີ່ຈື່ໄວ້ວ່າຫຼາຍຫົວຂໍ້ແມ່ນສັບສົນແທ້ໆແລະດັ່ງນັ້ນຈຶ່ງງ່າຍດາຍຫຼາຍ.

ກະລຸນາຮັບຊາບວ່າພວກເຮົາກຳລັງເວົ້າກ່ຽວກັບລະບົບ x86 64-ບິດທີ່ເຮັດວຽກຢູ່ໃນ Linux, ແລະຂ້ອຍພຽງແຕ່ສົມມຸດວ່າລະບົບຮອງຮັບ hugepages ທີ່ໂປ່ງໃສ (ເນື່ອງຈາກມັນບໍ່ແມ່ນຂໍ້ເສຍປຽບທີ່ 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(), ຫົວຂໍ້ນີ້ມີເສັ້ນໂຄ້ງການຮຽນຮູ້ທີ່ສູງຊັນຢ່າງບໍ່ໜ້າເຊື່ອ. ສະນັ້ນ, ຖ້າເຈົ້າຕັ້ງໃຈຈະເກັ່ງແທ້ໆ, ກຽມອ່ານ ແລະ ທົດສອບສອງສາມອາທິດກ່ອນເຈົ້າຈະຄາດຫວັງຜົນໄດ້ຮັບໃນທາງບວກ.

ອ່ານຫຍັງ?