ແນະນຳກ່ຽວກັບລະບົບປະຕິບັດການ

Hey Habr! ຂ້າພະເຈົ້າຢາກຈະເອົາມາໃຫ້ຄວາມສົນໃຈຂອງທ່ານຊຸດຂອງບົດຄວາມ - ການແປຂອງວັນນະຄະດີທີ່ຫນ້າສົນໃຈໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ - OSTEP. ເອກະສານນີ້ສົນທະນາຢ່າງເລິກເຊິ່ງກ່ຽວກັບການເຮັດວຽກຂອງລະບົບປະຕິບັດການທີ່ຄ້າຍຄື unix, ຄື, ເຮັດວຽກກັບຂະບວນການ, ຕາຕະລາງຕ່າງໆ, ຫນ່ວຍຄວາມຈໍາ, ແລະອົງປະກອບທີ່ຄ້າຍຄືກັນອື່ນໆທີ່ປະກອບເປັນ OS ທີ່ທັນສະໄຫມ. ທ່ານສາມາດເບິ່ງຕົ້ນສະບັບຂອງວັດສະດຸທັງຫມົດທີ່ນີ້ ທີ່ນີ້. ກະລຸນາຮັບຊາບວ່າການແປແມ່ນເຮັດບໍ່ໄດ້ເປັນມືອາຊີບ (ຂ້ອນຂ້າງເສລີ), ແຕ່ຂ້ອຍຫວັງວ່າຂ້ອຍຈະຮັກສາຄວາມຫມາຍທົ່ວໄປ.

ວຽກງານຫ້ອງທົດລອງກ່ຽວກັບເລື່ອງນີ້ສາມາດພົບໄດ້ທີ່ນີ້:

• ຕົ້ນສະບັບ
• ຕົ້ນສະບັບ
• ການປັບຕົວສ່ວນຕົວຂອງຂ້ອຍ

ພາກສ່ວນອື່ນໆ:

• ສ່ວນທີ 1: ແນະນຳ
• ພາກທີ 2: Abstraction: ຂະບວນການ
• ສ່ວນທີ 3: ການແນະນໍາ API ຂະບວນການ
• ສ່ວນທີ 4: ການແນະນຳຕົວກໍານົດເວລາ
• ສ່ວນທີ 5: ຕົວຈັດຕາຕະລາງ MLFQ

ທ່ານຍັງສາມາດກວດເບິ່ງຊ່ອງທາງຂອງຂ້ອຍໄດ້ທີ່ ໂທລະເລກ =)

ການວາງແຜນ: ຄິວຄໍາຕິຊົມຫຼາຍລະດັບ

ໃນການບັນຍາຍນີ້, ພວກເຮົາຈະສົນທະນາກ່ຽວກັບບັນຫາຂອງການພັດທະນາຫນຶ່ງໃນວິທີການທີ່ມີຊື່ສຽງທີ່ສຸດທີ່ຈະ
ການວາງແຜນ, ເຊິ່ງເອີ້ນວ່າ ຄິວຄໍາຕິຊົມຫຼາຍລະດັບ (MLFQ). ຕາຕະລາງ MLFQ ໄດ້ຖືກອະທິບາຍຄັ້ງທໍາອິດໃນປີ 1962 ໂດຍ Fernando J. Corbatóໃນລະບົບທີ່ເອີ້ນວ່າ
ລະບົບແບ່ງປັນເວລາເຂົ້າກັນໄດ້ (CTSS). ວຽກງານເຫຼົ່ານີ້ (ລວມທັງການເຮັດວຽກໃນພາຍຫຼັງ
Multics) ຕໍ່ມາໄດ້ຮັບການສະເໜີຊື່ໃຫ້ລາງວັນ Turing. ຕາຕະລາງແມ່ນ
ຕໍ່ມາປັບປຸງແລະໄດ້ມາລັກສະນະທີ່ສາມາດພົບເຫັນຢູ່ໃນແລ້ວ
ບາງລະບົບທີ່ທັນສະໄຫມ.

ສູດການຄິດໄລ່ MLFQ ພະຍາຍາມແກ້ໄຂບັນຫາການທັບຊ້ອນພື້ນຖານ 2 ອັນ.
ປະ​ການ​ທໍາ​ອິດ, ມັນພະຍາຍາມເພີ່ມປະສິດທິພາບທີ່ໃຊ້ເວລາ turnaround, ເຊິ່ງ, ດັ່ງທີ່ພວກເຮົາສົນທະນາໃນການບັນຍາຍທີ່ຜ່ານມາ, ແມ່ນການເພີ່ມປະສິດທິພາບໂດຍວິທີການເລີ່ມຕົ້ນຢູ່ໃນຫົວຂອງແຖວທີ່ສຸດ.
ວຽກ​ງານ​ສັ້ນ​. ຢ່າງໃດກໍຕາມ, OS ບໍ່ຮູ້ວ່າຂະບວນການນີ້ຈະດໍາເນີນການດົນປານໃດ, ແລະນີ້
ຄວາມຮູ້ທີ່ຈໍາເປັນສໍາລັບການປະຕິບັດງານຂອງ SJF, STCF algorithms. ທີສອງ, MLFQ ພະຍາຍາມ
ເຮັດໃຫ້ລະບົບຕອບສະຫນອງສໍາລັບຜູ້ໃຊ້ (ຕົວຢ່າງ, ສໍາລັບຜູ້ທີ່ນັ່ງແລະ
staring ຢູ່​ຫນ້າ​ຈໍ​ໃນ​ຂະ​ນະ​ທີ່​ລໍ​ຖ້າ​ສໍາ​ລັບ​ວຽກ​ງານ​ສໍາ​ເລັດ​) ແລະ​ດັ່ງ​ນັ້ນ​ການ​ຫຼຸດ​ຜ່ອນ​ເວ​ລາ​
ຕອບສະໜອງ. ແຕ່ຫນ້າເສຍດາຍ, algorithms ເຊັ່ນ RR ຫຼຸດຜ່ອນເວລາຕອບສະຫນອງ, ແຕ່
ມີຜົນກະທົບທີ່ບໍ່ດີຕໍ່ metric ທີ່ໃຊ້ເວລາ turnaround. ດັ່ງນັ້ນບັນຫາຂອງພວກເຮົາ: ວິທີການອອກແບບ
ຕາຕະລາງທີ່ຈະຕອບສະຫນອງຄວາມຕ້ອງການຂອງພວກເຮົາແລະໃນເວລາດຽວກັນບໍ່ຮູ້ຫຍັງກ່ຽວກັບ
ລັກສະນະຂອງຂະບວນການ, ໂດຍທົ່ວໄປ? ຜູ້ຈັດຕາຕະລາງສາມາດຮຽນຮູ້ຄຸນລັກສະນະຂອງວຽກງານໄດ້ແນວໃດ,
ທີ່ມັນເປີດຕົວແລະດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ການຕັດສິນໃຈກໍານົດເວລາທີ່ດີກວ່າ?

ຄວາມສໍາຄັນຂອງບັນຫາ: ວິທີການວາງແຜນການກໍານົດວຽກງານທີ່ບໍ່ມີຄວາມຮູ້ທີ່ສົມບູນແບບ?
ວິທີການອອກແບບຕາຕະລາງເວລາທີ່ຫຼຸດຜ່ອນເວລາຕອບໂຕ້
ສໍາລັບວຽກງານແບບໂຕ້ຕອບແລະໃນເວລາດຽວກັນຫຼຸດຜ່ອນເວລາ turnaround ໂດຍບໍ່ຮູ້ຕົວ
ຄວາມ​ຮູ້​ຂອງ​ການ​ໃຊ້​ເວ​ລາ​ປະ​ຕິ​ບັດ​ວຽກ​ງານ​?

ຫມາຍເຫດ: ການຮຽນຮູ້ຈາກເຫດການທີ່ຜ່ານມາ

ແຖວ MLFQ ເປັນຕົວຢ່າງທີ່ດີເລີດຂອງລະບົບທີ່ໄດ້ຮັບການຝຶກອົບຮົມ
ເຫດການທີ່ຜ່ານມາເພື່ອຄາດຄະເນອະນາຄົດ. ວິທີການດັ່ງກ່າວມັກຈະເປັນ
ພົບເຫັນຢູ່ໃນ OS (ແລະຫຼາຍສາຂາອື່ນໆໃນວິທະຍາສາດຄອມພິວເຕີ, ລວມທັງສາຂາ
ການຄາດຄະເນຮາດແວ ແລະ algorithms caching). ການຍ່າງປ່າທີ່ຄ້າຍຄືກັນ
ກະຕຸ້ນໃນເວລາທີ່ວຽກງານມີໄລຍະພຶດຕິກໍາແລະດັ່ງນັ້ນຈຶ່ງສາມາດຄາດເດົາໄດ້.
ຢ່າງໃດກໍຕາມ, ຫນຶ່ງຄວນຈະລະມັດລະວັງກັບເຕັກນິກນີ້, ເນື່ອງຈາກວ່າການຄາດຄະເນແມ່ນງ່າຍຫຼາຍ.
ອາດ​ຈະ​ກາຍ​ເປັນ​ການ​ຜິດ​ພາດ​ແລະ​ນໍາ​ພາ​ລະ​ບົບ​ການ​ຕັດ​ສິນ​ໃຈ​ຮ້າຍ​ແຮງ​ກວ່າ​
ຈະບໍ່ມີຄວາມຮູ້ຫຍັງເລີຍ.

MLFQ: ກົດລະບຽບພື້ນຖານ

ພິຈາລະນາກົດລະບຽບພື້ນຖານຂອງ MLFQ algorithm. ແລະເຖິງແມ່ນວ່າການປະຕິບັດຂອງ algorithm ນີ້
ມີຫຼາຍ, ວິທີການພື້ນຖານແມ່ນຄ້າຍຄືກັນ.
ໃນການປະຕິບັດທີ່ພວກເຮົາຈະພິຈາລະນາ, MLFQ ຈະມີຫຼາຍໆຢ່າງ
ແຖວແຍກຕ່າງຫາກ, ແຕ່ລະອັນຈະມີບູລິມະສິດທີ່ແຕກຕ່າງກັນ. ທຸກເວລາ,
ວຽກງານທີ່ກຽມພ້ອມສໍາລັບການປະຕິບັດແມ່ນຢູ່ໃນແຖວດຽວກັນ. MLFQ ໃຊ້ບູລິມະສິດ,
ເພື່ອຕັດສິນໃຈວ່າວຽກງານໃດທີ່ຈະດໍາເນີນການສໍາລັບການປະຕິບັດ, i.e. ວຽກ​ງານ​ທີ່​ສູງ​ກວ່າ​
ບູລິມະສິດ (ວຽກຈາກແຖວທີ່ມີບູລິມະສິດສູງສຸດ) ຈະຖືກເປີດຕົວໃນຄັ້ງທໍາອິດ
ຄິວ.
ແນ່ນອນ, ສາມາດມີຫຼາຍກວ່າຫນຶ່ງຫນ້າວຽກໃນແຖວສະເພາະ, ດັ່ງນັ້ນ
ດັ່ງນັ້ນພວກເຂົາຈະມີບູລິມະສິດດຽວກັນ. ໃນກໍລະນີນີ້, ກົນໄກຈະຖືກນໍາໃຊ້
RR ສໍາລັບການວາງແຜນການເປີດຕົວໃນບັນດາວຽກງານເຫຼົ່ານີ້.
ດັ່ງນັ້ນພວກເຮົາມາຮອດສອງກົດລະບຽບພື້ນຖານສໍາລັບ MLFQ:

• ກົດລະບຽບ 1: ຖ້າບູລິມະສິດ(A) > ບູລິມະສິດ(B), ວຽກງານ A ຈະດໍາເນີນການ (B ຈະບໍ່)
• Rule2: ຖ້າບູລິມະສິດ(A) = ບຸລິມະສິດ(B), A&B ແມ່ນເລີ່ມນຳໃຊ້ RR

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


ໃນໂຄງການນີ້, 2 ຂະບວນການ A ແລະ B ແມ່ນຢູ່ໃນແຖວທີ່ມີບູລິມະສິດສູງສຸດ. ຂະບວນການ
C ແມ່ນບາງບ່ອນຢູ່ກາງ, ແລະຂະບວນການ D ແມ່ນຢູ່ໃນຕອນທ້າຍຂອງແຖວ. ອີງຕາມການຂ້າງເທິງ
ຄໍາອະທິບາຍຂອງ MLFQ algorithm, ຜູ້ກໍານົດເວລາຈະປະຕິບັດຫນ້າວຽກທີ່ສູງສຸດເທົ່ານັ້ນ
ບູລິມະສິດຕາມ RR, ແລະວຽກງານ C, D ຈະອອກຈາກວຽກ.
ຕາມທໍາມະຊາດ, ພາບຖ່າຍແບບຄົງທີ່ຈະບໍ່ໃຫ້ຮູບພາບທີ່ສົມບູນຂອງວິທີການເຮັດວຽກຂອງ MLFQ.
ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈຢ່າງແນ່ນອນວ່າຮູບພາບມີການປ່ຽນແປງໃນໄລຍະເວລາ.

ຄວາມພະຍາຍາມ 1: ວິທີການປ່ຽນບູລິມະສິດ

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

• ກົດລະບຽບທີ 3: ເມື່ອວຽກງານເຂົ້າໄປໃນລະບົບ, ມັນຖືກຈັດໃສ່ໃນແຖວທີ່ມີຄ່າສູງສຸດ
• ບູລິມະສິດ.
• Rule4a: ຖ້າວຽກໃດນຶ່ງໃຊ້ໜ້າຈໍເວລາທັງໝົດຂອງມັນ, ຫຼັງຈາກນັ້ນມັນ
• ບູລິມະສິດຖືກຫຼຸດລົງ.
• Rule4b: ຖ້າ Task ປ່ອຍ CPU ກ່ອນທີ່ເວລາຂອງມັນຫມົດອາຍຸ, ຫຼັງຈາກນັ້ນມັນ
• ຍັງຄົງເປັນບູລິມະສິດອັນດຽວກັນ.

ຕົວຢ່າງທີ 1: ວຽກງານອັນດຽວທີ່ຍາວນານ

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


ຕົວຢ່າງທີ 2: ເກັບວຽກສັ້ນໆ

ຕອນນີ້ໃຫ້ເບິ່ງຕົວຢ່າງຂອງວິທີການ MLFQ ຈະພະຍາຍາມເຂົ້າຫາ SJF. ໃນ​ນັ້ນ
ຕົວຢ່າງ, ວຽກງານສອງຢ່າງ: A, ເຊິ່ງເປັນວຽກທີ່ຍາວນານຢ່າງຕໍ່ເນື່ອງ
ການຄອບຄອງ CPU ແລະ B, ເຊິ່ງເປັນວຽກງານການໂຕ້ຕອບສັ້ນ. ສົມມຸດວ່າ
ວ່າ A ໄດ້ແລ່ນໄປເປັນໄລຍະໜຶ່ງແລ້ວ ເມື່ອວຽກ B ມາຮອດ.


ເສັ້ນສະແດງນີ້ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບຂອງສະຖານະການ. ວຽກ​ງານ A, ເຊັ່ນ​ດຽວ​ກັນ​ກັບ​ວຽກ​ງານ​ໃດ​ຫນຶ່ງ,
ການນໍາໃຊ້ CPU ແມ່ນຢູ່ລຸ່ມສຸດ. Task B ຈະມາຮອດເວລາ T=100 ແລະຈະ
ຖືກຈັດໃສ່ໃນແຖວບູລິມະສິດສູງສຸດ. ເນື່ອງຈາກເວລາແລ່ນສັ້ນ,
ມັນຈະສໍາເລັດກ່ອນທີ່ມັນຈະມາຮອດແຖວສຸດທ້າຍ.

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

ຕົວຢ່າງ 3: I/O ແມ່ນຫຍັງ?

ຕອນນີ້ໃຫ້ເບິ່ງຕົວຢ່າງ I/O. ດັ່ງທີ່ໄດ້ກ່າວໄວ້ໃນກົດລະບຽບ 4b,
ຖ້າຂະບວນການປ່ອຍໂປເຊດເຊີໂດຍບໍ່ໄດ້ໃຊ້ເວລາຂອງໂປເຊດເຊີຢ່າງເຕັມທີ່,
ຫຼັງຈາກນັ້ນ, ມັນຍັງຄົງຢູ່ໃນລະດັບບູລິມະສິດດຽວກັນ. ຈຸດປະສົງຂອງກົດລະບຽບນີ້ແມ່ນງ່າຍດາຍ pretty.
- ຖ້າວຽກໂຕ້ຕອບເຮັດ I/O ຫຼາຍ, ຕົວຢ່າງ, ລໍຖ້າ
ຈາກການກົດແປ້ນພິມ ຫຼືເມົ້າຂອງຜູ້ໃຊ້, ວຽກງານດັ່ງກ່າວຈະເຮັດໃຫ້ໂປເຊດເຊີຟຣີ
ກ່ອນຫນ້າຕ່າງທີ່ໄດ້ຮັບ. ພວກເຮົາບໍ່ຢາກຍົກເລີກວຽກງານບູລິມະສິດດັ່ງກ່າວ,
ແລະດັ່ງນັ້ນມັນຈະຍັງຄົງຢູ່ໃນລະດັບດຽວກັນ.


ຕົວຢ່າງນີ້ສະແດງໃຫ້ເຫັນວິທີການ algorithm ຈະເຮັດວຽກກັບຂະບວນການດັ່ງກ່າວ - ວຽກງານການໂຕ້ຕອບ B, ເຊິ່ງຕ້ອງການພຽງແຕ່ CPU ສໍາລັບ 1ms ກ່ອນທີ່ຈະດໍາເນີນການ.
ຂະບວນການ I/O ແລະວຽກຍາວ A, ເຊິ່ງໃຊ້ CPU ຕະຫຼອດເວລາ.
MLFQ ຮັກສາຂະບວນການ B ຢູ່ໃນບູລິມະສິດສູງສຸດຍ້ອນວ່າມັນຍັງສືບຕໍ່
ປ່ອຍ CPU. ຖ້າ B ເປັນວຽກງານທີ່ມີການໂຕ້ຕອບ, ຫຼັງຈາກນັ້ນ algorithm ໃນກໍລະນີນີ້ໄດ້ບັນລຸ
ຈຸດປະສົງຂອງມັນແມ່ນເພື່ອເປີດວຽກງານການໂຕ້ຕອບຢ່າງໄວວາ.

ບັນຫາກັບ MLFQ algorithm ປະຈຸບັນ

ໃນຕົວຢ່າງທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ສ້າງສະບັບພື້ນຖານຂອງ MLFQ. ແລະເບິ່ງຄືວ່າລາວ
ເຮັດວຽກຂອງມັນໄດ້ດີແລະຍຸຕິທໍາ, ແຈກຢາຍເວລາ CPU ຢ່າງຍຸດຕິທໍາລະຫວ່າງ
ວຽກ​ງານ​ຍາວ​ແລະ​ໃຫ້​ວຽກ​ງານ​ສັ້ນ​ຫຼື​ວຽກ​ງານ​ທີ່​ມີ​ການ​ເຂົ້າ​ເຖິງ​ຫຼາຍ​
ໄປຫາ I/O ເພື່ອປະມວນຜົນຢ່າງໄວວາ. ແຕ່ຫນ້າເສຍດາຍ, ວິທີການນີ້ມີຫຼາຍໆຢ່າງ
ບັນຫາຮ້າຍແຮງ.
ປະ​ການ​ທໍາ​ອິດ, ບັນຫາຄວາມອຶດຫິວ: ຖ້າລະບົບຈະມີການໂຕ້ຕອບຫຼາຍ
ວຽກງານ, ພວກເຂົາຈະໃຊ້ເວລາ CPU ທັງຫມົດແລະດັ່ງນັ້ນບໍ່ແມ່ນເວລາດຽວ
ວຽກ ງານ ຈະ ບໍ່ ໄດ້ ຮັບ ໂອ ກາດ ທີ່ ຈະ ໄດ້ ຮັບ ການ ປະ ຕິ ບັດ (ພວກ ເຂົາ ເຈົ້າ ແມ່ນ starving).

ທີສອງ, ຜູ້ໃຊ້ smart ສາມາດຂຽນໂຄງການຂອງເຂົາເຈົ້າດັ່ງນັ້ນ
ໂງ່​ຜູ້​ກໍາ​ນົດ​ເວ​ລາ​ໄດ້​. ການຫລອກລວງແມ່ນຢູ່ໃນການເຮັດບາງສິ່ງບາງຢ່າງເພື່ອບັງຄັບ
ຕົວກໍານົດເວລາເພື່ອໃຫ້ຂະບວນການໃຊ້ເວລາ CPU ຫຼາຍ. ສູດການຄິດໄລ່ວ່າ
ອະທິບາຍຂ້າງເທິງນີ້ແມ່ນຂ້ອນຂ້າງມີຄວາມສ່ຽງຕໍ່ການໂຈມຕີດັ່ງກ່າວ: ກ່ອນທີ່ປ່ອງຢ້ຽມທີ່ໃຊ້ເວລາແມ່ນປະຕິບັດ
ຫຼາຍກວ່າ, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການ I / O (ກັບບາງ, ບໍ່ວ່າໄຟລ໌ໃດ)
ແລະດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ CPU ຫວ່າງ. ພຶດຕິກໍາດັ່ງກ່າວຈະເຮັດໃຫ້ເຈົ້າຢູ່ຄືກັນ
ແຖວຕົວມັນເອງແລະອີກເທື່ອຫນຶ່ງໄດ້ຮັບອັດຕາສ່ວນໃຫຍ່ຂອງເວລາ CPU. ຖ້າເຮັດແລ້ວ
ນີ້ແມ່ນຖືກຕ້ອງ (ເຊັ່ນ: ແລ່ນ 99% ຂອງເວລາປ່ອງຢ້ຽມກ່ອນທີ່ຈະປ່ອຍ CPU),
ວຽກງານດັ່ງກ່າວພຽງແຕ່ສາມາດຜູກຂາດໂຮງງານຜະລິດ.

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

ຄໍາຖາມກັບຜູ້ຊົມ: ການໂຈມຕີອັນໃດຕໍ່ຜູ້ກໍານົດເວລາສາມາດເຮັດໄດ້ໃນໂລກທີ່ທັນສະໄຫມ?

ຄວາມພະຍາຍາມ 2: ເພີ່ມບູລິມະສິດ

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

• ກົດລະບຽບ 5: ຫຼັງຈາກໄລຍະເວລາ S, ໂອນຫນ້າວຽກທັງຫມົດໃນລະບົບໄປຫາຄິວທີ່ສູງທີ່ສຸດ.

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


CPU ແລະສອງການໂຕ້ຕອບ, ຂະບວນການສັ້ນ. ຢູ່ເບື້ອງຊ້າຍໃນຮູບ, ຕົວເລກສະແດງໃຫ້ເຫັນເຖິງພຶດຕິກໍາທີ່ບໍ່ມີການຊຸກຍູ້ບູລິມະສິດ, ແລະດັ່ງນັ້ນ, ວຽກງານທີ່ຍາວນານເລີ່ມອຶດຫິວຫຼັງຈາກສອງວຽກງານການໂຕ້ຕອບມາຮອດລະບົບ. ໃນຮູບດ້ານຂວາ, ທຸກໆ 50ms ການເພີ່ມບູລິມະສິດແມ່ນປະຕິບັດແລະດັ່ງນັ້ນຂະບວນການທັງຫມົດແມ່ນຮັບປະກັນວ່າຈະໄດ້ຮັບເວລາຂອງໂປເຊດເຊີແລະຈະເລີ່ມຕົ້ນເປັນແຕ່ລະໄລຍະ. 50ms ໃນກໍລະນີນີ້ຖືກເອົາເປັນຕົວຢ່າງ, ໃນຄວາມເປັນຈິງ, ຕົວເລກນີ້ແມ່ນຂ້ອນຂ້າງສູງ.
ແນ່ນອນ, ການເພີ່ມໄລຍະເວລາເພີ່ມຂຶ້ນ S ນໍາໄປສູ່
ຄໍາຖາມຢ່າງມີເຫດຜົນ: ຄວນກໍານົດຄ່າໃດ? ຫນຶ່ງໃນດີສົມຄວນ
ວິສະວະກອນລະບົບ John Ousterhout ໄດ້ກ່າວເຖິງປະລິມານທີ່ຄ້າຍຄືກັນໃນລະບົບເປັນ voo-doo
ຄົງທີ່, ນັບຕັ້ງແຕ່ພວກເຂົາໃນບາງທາງຕ້ອງການ magic ສີດໍາສໍາລັບທີ່ຖືກຕ້ອງ
​ການ​ສຳ​ຜັດ​ເຊື້ອ. ແລະ, ແຕ່ຫນ້າເສຍດາຍ, S ມີລົດຊາດດັ່ງກ່າວ. ຖ້າເຈົ້າຕັ້ງຄ່າຄືກັນ
ຂະ​ຫນາດ​ໃຫຍ່ - ວຽກ​ງານ​ຍາວ​ຈະ starve​. ແລະ ຖ້າ​ເຈົ້າ​ຕັ້ງ​ມັນ​ຕ່ຳ​ເກີນ​ໄປ,
ວຽກງານແບບໂຕ້ຕອບຈະບໍ່ໄດ້ຮັບເວລາ CPU ທີ່ເຫມາະສົມ.

ຄວາມພະຍາຍາມ 3: ບັນຊີທີ່ດີກວ່າ

ໃນ​ປັດ​ຈຸ​ບັນ​ພວກ​ເຮົາ​ມີ​ອີກ​ຫນຶ່ງ​ບັນ​ຫາ​ທີ່​ຈະ​ແກ້​ໄຂ​: ເຮັດ​ແນວ​ໃດ​ບໍ່​ໄດ້​
ອະນຸຍາດໃຫ້ໂກງຕາຕະລາງຂອງພວກເຮົາ? culprits ສໍາລັບຄວາມເປັນໄປໄດ້ນີ້ແມ່ນ
ກົດລະບຽບ 4a, 4b ທີ່ອະນຸຍາດໃຫ້ເຮັດວຽກເພື່ອຮັກສາບູລິມະສິດຂອງຕົນໂດຍການປົດປ່ອຍໂປເຊດເຊີ
ກ່ອນໝົດກຳນົດເວລາທີ່ໄດ້ຮັບ. ວິທີການຈັດການກັບມັນ?
ການແກ້ໄຂໃນກໍລະນີນີ້ສາມາດຖືວ່າເປັນບັນຊີທີ່ດີກວ່າຂອງເວລາ CPU ໃນແຕ່ລະຄົນ
ລະດັບ MLFQ. ແທນທີ່ຈະລືມເວລາທີ່ໂຄງການໃຊ້
ໂຮງງານຜະລິດສໍາລັບໄລຍະເວລາທີ່ໄດ້ຮັບ, ທ່ານຄວນພິຈາລະນາແລະປະຫຍັດມັນ. ຫຼັງຈາກ
ຂະ​ບວນ​ການ​ໄດ້​ໃຊ້​ເວ​ລາ​ທີ່​ໄດ້​ຮັບ​ການ​ຈັດ​ສັນ​ຂອງ​ຕົນ​, ມັນ​ຄວນ​ຈະ​ໄດ້​ຮັບ​ການ demoted ໄປ​ຕໍ່​ໄປ​
ລະດັບບູລິມະສິດ. ໃນປັດຈຸບັນມັນບໍ່ສໍາຄັນວ່າຂະບວນການຈະໃຊ້ເວລາຂອງມັນ - ແນວໃດ
ຄອມ​ພິວ​ເຕີ​ຢູ່​ສະ​ເຫມີ​ໃນ​ໂຮງ​ງານ​ຜະ​ລິດ​ຫຼື​ເປັນ​ຊຸດ​ຂອງ​ການ​ໂທ​. ດັ່ງນັ້ນ,
ກົດລະບຽບ 4 ຄວນຖືກຂຽນຄືນໃຫມ່ດັ່ງຕໍ່ໄປນີ້:

• ກົດລະບຽບ 4: ຫຼັງຈາກວຽກໃດນຶ່ງໄດ້ໃຊ້ເວລາທີ່ຈັດສັນຢູ່ໃນຄິວປັດຈຸບັນ (ບໍ່ວ່າມັນຈະປ່ອຍ CPU ເທົ່າໃດ), ບູລິມະສິດຂອງວຽກດັ່ງກ່າວຈະຫຼຸດລົງ (ມັນເລື່ອນລົງຕາມຄິວ).

ຂໍ​ໃຫ້​ເບິ່ງ​ຕົວ​ຢ່າງ​:
»

ຕົວເລກສະແດງໃຫ້ເຫັນສິ່ງທີ່ເກີດຂື້ນຖ້າທ່ານພະຍາຍາມຫລອກລວງຜູ້ຈັດຕາຕະລາງເຊັ່ນ
ຖ້າມັນຢູ່ກັບກົດລະບຽບທີ່ຜ່ານມາ 4a, 4b ຈະເປັນຜົນໄດ້ຮັບຢູ່ເບື້ອງຊ້າຍ. ກັບໃຫມ່
ກົດລະບຽບແມ່ນຜົນໄດ້ຮັບແມ່ນຢູ່ເບື້ອງຂວາ. ກ່ອນ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​, ຂະ​ບວນ​ການ​ໃດ​ຫນຶ່ງ​ສາ​ມາດ​ໂທ​ຫາ I/O ກ່ອນ​ທີ່​ຈະ​ສໍາ​ເລັດ​ແລະ​
ດັ່ງນັ້ນຈຶ່ງຄອບງໍາ CPU, ຫຼັງຈາກເປີດໃຊ້ການປົກປ້ອງ, ໂດຍບໍ່ສົນເລື່ອງຂອງພຶດຕິກໍາ
I/O, ລາວຍັງຈະລົງໃນແຖວແລະດັ່ງນັ້ນຈຶ່ງບໍ່ສາມາດທີ່ຈະບໍ່ຊື່ສັດ
ເອົາຊັບພະຍາກອນ CPU.

ການປັບປຸງ MLFQ ແລະບັນຫາອື່ນໆ

ດ້ວຍການປັບປຸງຂ້າງເທິງ, ບັນຫາໃຫມ່ເກີດຂື້ນ: ຫນຶ່ງໃນຕົ້ນຕໍ
ຄໍາຖາມ - ວິທີການກໍານົດຕາຕະລາງດັ່ງກ່າວ? ເຫຼົ່ານັ້ນ. ຄວນເທົ່າໃດ
ຄິວ? ສິ່ງທີ່ຄວນເປັນຂະຫນາດຂອງປ່ອງຢ້ຽມຂອງໂຄງການພາຍໃນແຖວ? ແນວໃດ
ໂຄງການມັກຈະຖືກຈັດລໍາດັບຄວາມສໍາຄັນເພື່ອຫຼີກເວັ້ນການ starvation ແລະ
ຄໍານຶງເຖິງການປ່ຽນແປງໃນພຶດຕິກໍາຂອງໂຄງການ? ສໍາລັບຄໍາຖາມເຫຼົ່ານີ້, ບໍ່ມີງ່າຍດາຍ
ການຕອບສະ ໜອງ ແລະພຽງແຕ່ການທົດລອງກັບການໂຫຼດແລະການຕັ້ງຄ່າຕໍ່ໄປ
ຕາຕະລາງສາມາດນໍາໄປສູ່ຄວາມສົມດຸນທີ່ຫນ້າພໍໃຈ.

ຕົວຢ່າງ, ການປະຕິບັດ MLFQ ສ່ວນໃຫຍ່ອະນຸຍາດໃຫ້ທ່ານມອບຫມາຍທີ່ແຕກຕ່າງກັນ
ຊ່ອງເວລາສໍາລັບແຖວທີ່ແຕກຕ່າງກັນ. ປົກກະຕິຄິວບູລິມະສິດສູງ
ໄລ​ຍະ​ສັ້ນ​. ແຖວເຫຼົ່ານີ້ປະກອບດ້ວຍວຽກງານການໂຕ້ຕອບ,
ສະຫຼັບລະຫວ່າງທີ່ຂ້ອນຂ້າງອ່ອນໄຫວ ແລະຄວນໃຊ້ເວລາ 10 ຫຼືໜ້ອຍກວ່າ
ນາງ​ສາວ. ໃນທາງກົງກັນຂ້າມ, ແຖວບູລິມະສິດຕໍ່າປະກອບດ້ວຍວຽກງານທີ່ຍາວນານທີ່ໃຊ້
CPU. ແລະໃນກໍລະນີນີ້, ໄລຍະຫ່າງທີ່ຍາວນານເຫມາະຫຼາຍ (100ms).


ໃນຕົວຢ່າງນີ້, ມີ 2 ວຽກງານທີ່ໄດ້ເຮັດວຽກຢູ່ໃນແຖວບູລິມະສິດສູງ 20
ms ແບ່ງອອກເປັນ 10ms windows. 40ms ໃນແຖວກາງ (ຫນ້າຕ່າງ 20ms) ແລະຢູ່ໃນຄິວທີ່ມີບູລິມະສິດຕໍ່າ
ປ່ອງຢ້ຽມເວລາຄິວກາຍເປັນ 40ms ບ່ອນທີ່ວຽກງານສໍາເລັດວຽກງານຂອງພວກເຂົາ.

ການປະຕິບັດ MLFQ ໃນ Solaris OS ແມ່ນຫ້ອງຮຽນຂອງຕາຕະລາງການແບ່ງປັນເວລາ.
ຜູ້ກໍານົດເວລາຈະສະຫນອງຊຸດຂອງຕາຕະລາງທີ່ກໍານົດຢ່າງແນ່ນອນວ່າມັນຄວນຈະເປັນແນວໃດ
ປ່ຽນບູລິມະສິດຂອງຂະບວນການໃນໄລຍະຊີວິດຂອງມັນ, ສິ່ງທີ່ຄວນຈະເປັນຂະຫນາດ
ປ່ອງ​ຢ້ຽມ​ທີ່​ຈະ​ໄດ້​ຮັບ​ການ​ຈັດ​ສັນ​ແລະ​ມັກ​ຈະ​ຍົກ​ສູງ​ຄວາມ​ສໍາ​ຄັນ​ວຽກ​ງານ​. ຜູ້​ບໍ​ລິ​ຫານ
ລະບົບສາມາດພົວພັນກັບຕາຕະລາງນີ້ແລະເຮັດໃຫ້ຜູ້ກໍານົດເວລາປະຕິບັດຕົວ
ແຕກຕ່າງກັນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕາຕະລາງນີ້ມີ 60 ຄິວທີ່ມີການເພີ່ມຂຶ້ນເທື່ອລະກ້າວ
ຂະຫນາດປ່ອງຢ້ຽມຈາກ 20ms (ບູລິມະສິດສູງ) ຫາຫຼາຍຮ້ອຍ ms (ບູລິມະສິດຕ່ໍາສຸດ), ແລະ
ພ້ອມ​ທັງ​ເພີ່ມ​ທະ​ວີ​ວຽກ​ງານ​ທັງ​ຫມົດ​ຫນຶ່ງ​ຄັ້ງ​ຕໍ່​ວິ​ນາ​ທີ​.

ຕາຕະລາງ MLFQ ອື່ນໆບໍ່ໄດ້ໃຊ້ຕາຕະລາງຫຼືສະເພາະໃດໆ
ກົດລະບຽບທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດນີ້, ໃນທາງກົງກັນຂ້າມ, ພວກເຂົາຄິດໄລ່ຄວາມສໍາຄັນໂດຍໃຊ້
ສູດ​ຄະ​ນິດ​ສາດ​. ຕົວຢ່າງ, ຕົວກໍານົດເວລາໃນ FreeBSD ໃຊ້ສູດສໍາລັບ
ການຄິດໄລ່ບູລິມະສິດວຽກງານໃນປະຈຸບັນໂດຍອີງໃສ່ຂະບວນການຫຼາຍປານໃດ
ໃຊ້ CPU. ນອກຈາກນັ້ນ, ການນໍາໃຊ້ CPU rot ໃນໄລຍະເວລາ, ແລະດັ່ງນັ້ນ
ດັ່ງນັ້ນ, ການເພີ່ມບູລິມະສິດແມ່ນແຕກຕ່າງກັນຫຼາຍກ່ວາທີ່ອະທິບາຍຂ້າງເທິງ. ນີ້​ແມ່ນ​ຄວາມ​ຈິງ
ເອີ້ນວ່າ algorithms decay. ໃນຖານະເປັນສະບັບ 7.1, FreeBSD ໃຊ້ຕົວກໍານົດເວລາ ULE.

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

MLFQ: ສະຫຼຸບ

ພວກເຮົາໄດ້ອະທິບາຍວິທີການວາງແຜນທີ່ເອີ້ນວ່າ MLFQ. ຊື່​ຂອງ​ລາວ
ສະຫຼຸບໃນຫຼັກການຂອງການດໍາເນີນງານ - ມັນມີຫຼາຍໆຄິວແລະນໍາໃຊ້ຄໍາຄຶດຄໍາເຫັນ
ເພື່ອຈັດລໍາດັບຄວາມສໍາຄັນຂອງວຽກງານ.
ຮູບແບບສຸດທ້າຍຂອງກົດລະບຽບຈະເປັນດັ່ງຕໍ່ໄປນີ້:

• ກົດລະບຽບ 1: ຖ້າບູລິມະສິດ(A) > ບຸລິມະສິດ(B), ວຽກ A ຈະດໍາເນີນການ (B ຈະບໍ່)
• ກົດລະບຽບ 2: ຖ້າບຸລິມະສິດ(A) = ບຸລິມະສິດ(B), A&B ແມ່ນເລີ່ມນຳໃຊ້ RR
• ກົດລະບຽບ 3: ເມື່ອວຽກໃດນຶ່ງເຂົ້າມາໃນລະບົບ, ມັນຈະຖືກຈັດໃສ່ໃນແຖວບູລິມະສິດສູງສຸດ.
• ກົດລະບຽບ 4: ຫຼັງຈາກວຽກໃດນຶ່ງໄດ້ໃຊ້ເວລາທີ່ຈັດສັນຢູ່ໃນຄິວປັດຈຸບັນ (ບໍ່ວ່າມັນຈະປ່ອຍ CPU ເທົ່າໃດ), ບູລິມະສິດຂອງວຽກດັ່ງກ່າວຈະຫຼຸດລົງ (ມັນເລື່ອນລົງຕາມຄິວ).
• ກົດລະບຽບ 5: ຫຼັງຈາກໄລຍະເວລາ S, ໂອນຫນ້າວຽກທັງຫມົດໃນລະບົບໄປຫາຄິວທີ່ສູງທີ່ສຸດ.

MLFQ ແມ່ນຫນ້າສົນໃຈສໍາລັບເຫດຜົນຕໍ່ໄປນີ້ - ແທນທີ່ຈະຕ້ອງການຄວາມຮູ້ກ່ຽວກັບ
ລັກສະນະຂອງວຽກງານລ່ວງຫນ້າ, algorithm ຮຽນຮູ້ພຶດຕິກໍາທີ່ຜ່ານມາຂອງວຽກງານແລະຊຸດ
ບູລິມະສິດຕາມຄວາມເຫມາະສົມ. ດັ່ງນັ້ນ, ລາວພະຍາຍາມນັ່ງຢູ່ເທິງເກົ້າອີ້ສອງຕົວໃນເວລາດຽວກັນ - ເພື່ອບັນລຸການປະຕິບັດສໍາລັບວຽກງານຂະຫນາດນ້ອຍ (SJF, STCF) ແລະແລ່ນຢ່າງຊື່ສັດ,
ວຽກການໂຫຼດ CPU. ດັ່ງນັ້ນ, ຫຼາຍລະບົບ, ລວມທັງ BSD ແລະອະນຸພັນຂອງພວກມັນ,
Solaris, Windows, Mac ໃຊ້ບາງຮູບແບບຂອງ algorithm ເປັນຕົວກໍານົດເວລາ
MLFQ ເປັນພື້ນຖານ.

ອຸປະກອນເພີ່ມເຕີມ:

1. manpages.debian.org/stretch/manpages/sched.7.en.html
2. en.wikipedia.org/wiki/Scheduling_(ຄອມພິວເຕີ້)
3. pages.lip6.fr/Julia.Lawall/atc18-bouron.pdf
4. www.usenix.org/legacy/event/bsdcon03/tech/full_papers/roberson/roberson.pdf
5. chebykin.org/freebsd-process-scheduling

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