เนื้อหาของตารางหน้าจะมีลักษณะอย่างไรหลังจากที่เพจถูกสลับไปยังดิสก์


1

จากสิ่งที่ฉันเข้าใจตารางหน้าจะจับคู่ที่อยู่เสมือนกับที่อยู่ทางกายภาพ แต่จะเกิดอะไรขึ้นหากมีการสลับหน้าออกไปยังดิสก์ ที่ตั้งของข้อมูลจะไม่ใช้บิตในการเขียนมากกว่าที่อยู่จริงหรือไม่ ตำแหน่งของข้อมูลไม่เปลี่ยนแปลงเมื่อมีการแก้ไขไฟล์สลับหรือไม่ ปัญหานี้ได้รับการแก้ไขด้วยวิธีที่ต่างกันในระบบปฏิบัติการที่แตกต่างกันหรือไม่?

คำตอบ:


1

ลองทำคำถามที่ง่ายขึ้นก่อน:

ตำแหน่งของข้อมูลไม่เปลี่ยนแปลงเมื่อมีการแก้ไขไฟล์สลับหรือไม่

ไม่มีการแก้ไข pagefile ที่ทำให้ตำแหน่งของข้อมูลที่มีอยู่นั้นเปลี่ยนแปลง หากมีการขยายหน้าไฟล์จะมีการเพิ่มกลุ่ม (จัดกลุ่มใน "ส่วนขยาย" หรือ "เรียกใช้") ไปยังจุดสิ้นสุดดังนั้นตำแหน่งของข้อมูลที่มีอยู่จะไม่เปลี่ยนแปลง ตำแหน่งของเพจไฟล์นั้นสัมพันธ์กับการเริ่มต้นของเพจไฟล์เสมอดังนั้นแม้ว่าจะมีการย้ายส่วนขยายที่มีอยู่แล้วอยู่ก็ตามตำแหน่งของไฟล์เพจจะไม่เปลี่ยนแปลง

ตอนนี้เกี่ยวกับบิต:

ที่ตั้งของข้อมูลจะไม่ใช้บิตในการเขียนมากกว่าที่อยู่จริงหรือไม่

ใช่ถ้า pagefile สามารถมีขนาดใหญ่กว่าขนาดหน่วยความจำฟิสิคัลที่เป็นไปได้คุณจะต้องใช้บิตเพิ่มเติมเพื่อระบุเพจภายใน pagefile มากกว่าบิตเพื่อระบุหมายเลขหน้าฟิสิคัล

ใน x86 ที่ไม่ได้เปิดใช้งาน PAE จะมี 20 บิตในรายการตารางหน้า (PTE) สำหรับหมายเลขหน้าจริง (PFN หรือย่อมาจาก "หมายเลขเฟรมหน้า") (PTE คือ 32 บิตส่วนอีก 12 คือบิตแฟล็กบิต 0 เป็นบิต "ถูกต้อง" หรือ "หน้าปัจจุบัน" ที่ระบุว่าคุณจะไม่ได้รับข้อบกพร่องของหน้าเมื่อคุณอ้างอิงหน้านั้น ใช้โดยระบบปฏิบัติการอื่น ๆ มีความหมายเช่น "อ่านอย่างเดียว", "เข้าถึงได้เฉพาะในโหมดเคอร์เนล", "แคชปิดใช้งาน" ฯลฯ ) (ทุกสิ่งในวรรคนี้ถูกกำหนดโดยสถาปัตยกรรม CPU - เป็นอิสระจากระบบปฏิบัติการ)

ใน Windows บิตเดียวกันใน PTE ที่เก็บ PFN สำหรับหน้าที่ถูกต้องสำหรับหน้าเว็บที่อยู่ใน pagefile จะใช้เพื่อเก็บตำแหน่ง location-page-pagefile สิ่งนี้แสดงเป็นออฟเซ็ตในหน่วยขนาดหน้าจากจุดเริ่มต้นของ pagefile สิ่งนี้จะ จำกัด pagefiles เป็น 4 GB เช่นเดียวกับ PFN แบบ 20 บิตสำหรับหน้าฟิสิคัล จำกัด RAM ไว้ที่ 4 GB ในระบบเหล่านี้

อย่างไรก็ตามคุณสามารถมีหลายไฟล์ได้ มีบิตอีกสี่บิตใน PTE ซึ่งสำหรับหน้าใน pagefile ระบุหมายเลข pagefile ดังนั้นจึงสามารถมีไฟล์ได้ 16 ไฟล์สำหรับพื้นที่เพจไฟล์ที่เป็นไปได้ 64 GB

เมื่อคุณเปิดใช้งาน PAE บนโปรเซสเซอร์ x86 แบบเก่าเท่านั้น PTEs จะมีความกว้าง 64 บิตและ CPU ใช้ 24 บิต (เพิ่มจาก 20) ของ PFN ใน PTE อนุญาตให้ใช้ RAM 64 GB และใน Windows, 64 GB pagefiles มีบิตจำนวนมากที่ไม่ได้ใช้ในรูปแบบ PTE ดังนั้นระบบปฏิบัติการจึงสามารถรองรับไฟล์ขนาดใหญ่ได้ ฉันไม่แน่ใจว่า Windows 32 บิตทำหรือไม่

ในตัวประมวลผล 64 บิตที่ใหม่กว่าในโหมด 64 บิตมี PFN 40 บิตและอีกครั้งจะใช้บิตเดียวกันนี้เพื่อจัดเก็บ pagefile offset สำหรับหน้าไม่ถูกต้อง (เช่นไม่มีอยู่ในปัจจุบัน) ดังนั้น RAM หรือ pagefile เราสามารถอธิบาย 2 ^ 40 หน้า - นั่นคือหนึ่งใน "ไบนารีล้านล้าน" ของหน้า 1024 ถึง 4 และแต่ละหน้ามีค่า 4 KiB ดังนั้น pagefile ขนาด 4 PiB จึงเป็นค่าสูงสุดและ RAM สูงสุดที่ฮาร์ดแวร์รองรับ และอีกครั้ง Windows บอกว่าคุณสามารถมีหลายไฟล์ได้ ฉันไม่คิดว่าเราจะพบข้อ จำกัด เกี่ยวกับพื้นที่หน้าไฟล์ได้ทุกเวลาเร็ว ๆ นี้ :)

ทั้งหมดที่กล่าวมาข้างต้นไม่ได้ถูกบังคับใช้โดย CPU นั้นเป็นเพียงระบบปฏิบัติการ จริง ๆ แล้วไม่มีเหตุผลใดที่ตำแหน่ง location-page-pagefile จะต้องถูกเก็บไว้ใน PTE เลย; สามารถใช้โครงสร้างอื่นได้ เกี่ยวกับโปรเซสเซอร์เช่น PowerPC ที่ใช้ตารางเพจที่แฮชระบบปฏิบัติการ ลาด เก็บไว้ใน PTE เนื่องจาก PTE ที่ไม่ถูกต้องจะไม่ถูกจัดเก็บในโครงสร้าง HPT

แต่ใน x86 / x64 มีเหตุผลจริงๆที่จะไม่ใช้ PTE ที่ไม่ถูกต้อง วิธีนี้ใช้ได้ผลเพราะเมื่อบิต "ถูกต้อง" ชัดเจน MMU ไม่สนใจบิต (ปุนตั้งใจ) สำหรับส่วนที่เหลือของ PTE ดังนั้นสำหรับ PTE ที่ไม่ถูกต้องจะมีเพียงบิตเดียวเท่านั้นที่ระบบปฏิบัติการจะใช้ได้ ในความเป็นจริง Windows มีรูปแบบอื่น ๆ ของ "PTE ที่ไม่ถูกต้อง" หลายรูปแบบขึ้นอยู่กับสถานะของหน้า สำหรับเพจในรายการสแตนด์บายหรือรายการที่แก้ไขตัวอย่างเช่นฟิลด์ PFN จะยังคงมีตำแหน่งฟิสิคัลของเพจใน RAM PTE สำหรับหน้าที่ไม่ถูกต้องอาจอ้างถึง "virtual address descriptor" หรือหากเป็นหน้าที่แชร์ไปยัง "prototype PTE" MMU ฮาร์ดแวร์ไม่เคยเห็นโครงสร้างเหล่านั้นอย่างใดอย่างหนึ่งเฉพาะ PTE

รายละเอียดทั้งหมดอยู่ในบท "การจัดการหน่วยความจำ" ของ Windows Internals โดยโซโลมอน Russinovich และ Ionescu


ขอบคุณสำหรับข้อเสนอแนะที่ดี! หากคุณมีคำถามติดตามผลอย่าลังเลที่จะโพสต์ไว้เป็นความคิดเห็นหรือแก้ไขคำถามเดิมของคุณ
Jamie Hanrahan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.