Phần mềm chạy trên hệ điều hành trên một cơ sở rất đơn giản - chúng yêu cầu bộ nhớ. Hệ điều hành của thiết bị cung cấp nó dưới dạng RAM. Dung lượng bộ nhớ cần thiết có thể khác nhau - một số phần mềm cần bộ nhớ lớn, một số yêu cầu bộ nhớ nhỏ. Hầu hết (nếu không phải tất cả) người dùng chạy đồng thời nhiều ứng dụng trên HĐH và do bộ nhớ đắt (và kích thước thiết bị là hữu hạn), dung lượng bộ nhớ có sẵn luôn bị giới hạn. Vì vậy, do tất cả các phần mềm đều yêu cầu một lượng RAM nhất định và tất cả chúng đều có thể chạy cùng một lúc, hệ điều hành phải đảm nhận hai điều:
- Rằng phần mềm luôn chạy cho đến khi người dùng hủy bỏ nó, tức là nó không được tự động hủy bỏ vì hệ điều hành đã hết bộ nhớ.
- Hoạt động trên, trong khi vẫn duy trì một hiệu suất đáng nể cho các phần mềm đang chạy.
Bây giờ câu hỏi chính xoay quanh cách quản lý bộ nhớ. Điều gì chi phối chính xác vị trí của dữ liệu thuộc một phần mềm nhất định sẽ nằm ở đâu trong bộ nhớ?
Giải pháp khả thi 1 : Để các phần mềm riêng lẻ chỉ định rõ ràng địa chỉ bộ nhớ mà chúng sẽ sử dụng trong thiết bị. Giả sử Photoshop tuyên bố rằng nó sẽ luôn sử dụng các địa chỉ bộ nhớ nằm trong khoảng từ 0đến 1023(hãy tưởng tượng bộ nhớ như một mảng tuyến tính của các byte, do đó byte đầu tiên ở vị trí 0, 1024byte thứ ở vị trí 1023) - tức là chiếm 1 GBbộ nhớ. Tương tự như vậy, VLC tuyên bố rằng nó sẽ chiếm nhiều bộ nhớ 1244để 1876vv
Ưu điểm:
- Mọi ứng dụng đều được gán sẵn một khe cắm bộ nhớ, vì vậy khi được cài đặt và thực thi, ứng dụng chỉ lưu dữ liệu của mình trong vùng bộ nhớ đó và mọi thứ hoạt động tốt.
Nhược điểm:
Điều này không quy mô. Về mặt lý thuyết, một ứng dụng có thể yêu cầu một lượng lớn bộ nhớ khi nó thực hiện một công việc thực sự nặng nề. Vì vậy, để đảm bảo rằng nó không bao giờ hết bộ nhớ, vùng bộ nhớ được cấp cho nó phải luôn lớn hơn hoặc bằng dung lượng bộ nhớ đó. Điều gì sẽ xảy ra nếu một phần mềm, có mức sử dụng bộ nhớ lý thuyết tối đa 2 GB(do đó yêu cầu cấp phát 2 GBbộ nhớ từ RAM), được cài đặt trong một máy chỉ có 1 GBbộ nhớ? Phần mềm có nên hủy bỏ khi khởi động, nói rằng RAM khả dụng ít hơn 2 GBkhông? Hay nó sẽ tiếp tục và thời điểm bộ nhớ cần thiết vượt quá 2 GB, chỉ cần hủy bỏ và cứu trợ với thông báo không đủ bộ nhớ khả dụng?
Không thể ngăn chặn việc xáo trộn bộ nhớ. Có hàng triệu phần mềm ngoài kia, ngay cả khi mỗi phần mềm trong số chúng chỉ được phân bổ 1 kBbộ nhớ, tổng bộ nhớ cần thiết sẽ vượt quá 16 GB, nhiều hơn hầu hết các thiết bị cung cấp. Vậy thì làm thế nào để các phần mềm khác nhau được phân bổ các khe cắm bộ nhớ mà không xâm phạm các khu vực của nhau? Thứ nhất, không có thị trường phần mềm tập trung nào có thể quy định rằng khi một phần mềm mới được phát hành, nó phải tự gán cho mình nhiều bộ nhớ từ khu vực chưa được sử dụng này, và thứ hai, ngay cả khi có, bạn không thể làm điều đó vì không có. thực tế của phần mềm là vô hạn (do đó yêu cầu bộ nhớ vô hạn để chứa tất cả chúng) và tổng bộ nhớ RAM có sẵn trên bất kỳ thiết bị nào không đủ để chứa dù chỉ một phần nhỏ của những gì được yêu cầu, do đó không thể tránh khỏi việc xâm phạm giới hạn bộ nhớ của một phần mềm dựa trên cái khác. Vậy điều gì sẽ xảy ra khi Photoshop được gán địa chỉ ô nhớ 1đến 1023và VLC được gán 1000tới 1676? Điều gì sẽ xảy ra nếu Photoshop lưu trữ một số dữ liệu tại vị trí 1008, sau đó VLC ghi đè dữ liệu đó bằng dữ liệu của chính nó và sau đó là Photoshoptruy cập nó vì nghĩ rằng nó là cùng một dữ liệu đã được lưu trữ ở đó trước đó? Như bạn có thể tưởng tượng, những điều tồi tệ sẽ xảy ra.
Rõ ràng, như bạn có thể thấy, ý tưởng này khá là ngây thơ.
Giải pháp khả thi 2 : Hãy thử một sơ đồ khác - nơi OS sẽ thực hiện phần lớn việc quản lý bộ nhớ. Phần mềm, bất cứ khi nào chúng yêu cầu bất kỳ bộ nhớ nào, sẽ chỉ yêu cầu hệ điều hành và hệ điều hành sẽ đáp ứng cho phù hợp. Giả sử OS đảm bảo rằng bất cứ khi nào một tiến trình mới yêu cầu bộ nhớ, nó sẽ cấp phát bộ nhớ từ địa chỉ byte thấp nhất có thể (như đã nói trước đó, RAM có thể được hình dung như một mảng tuyến tính của các byte, vì vậy đối với 4 GBRAM, phạm vi địa chỉ cho byte từ 0đến2^32-1) nếu tiến trình đang bắt đầu, ngược lại nếu là tiến trình đang chạy yêu cầu bộ nhớ, nó sẽ cấp phát từ vị trí bộ nhớ cuối cùng nơi tiến trình đó vẫn còn ở. Vì phần mềm sẽ phát ra địa chỉ mà không cần xem xét địa chỉ bộ nhớ thực sẽ là nơi lưu trữ dữ liệu đó, OS sẽ phải duy trì ánh xạ địa chỉ do phần mềm phát ra với địa chỉ thực thực tế (Lưu ý: đó là một trong hai lý do chúng tôi gọi khái niệm này Virtual Memory. Phần mềm không quan tâm đến địa chỉ bộ nhớ thực nơi dữ liệu của họ đang được lưu trữ, họ chỉ tìm ra địa chỉ một cách nhanh chóng và hệ điều hành tìm đúng nơi phù hợp với nó và tìm thấy nó sau nếu được yêu cầu).
Giả sử thiết bị vừa được bật, hệ điều hành vừa khởi chạy, ngay lúc này không có tiến trình nào khác đang chạy (bỏ qua hệ điều hành, đó cũng là một quy trình!), Và bạn quyết định khởi chạy VLC . Vì vậy, VLC được cấp phát một phần RAM từ các địa chỉ byte thấp nhất. Tốt. Bây giờ trong khi video đang chạy, bạn cần khởi động trình duyệt của mình để xem một số trang web. Sau đó, bạn cần khởi chạy Notepad để viết nguệch ngoạc một số văn bản. Và sau đó Eclipse để thực hiện một số mã hóa .. Rất nhanh chóng bộ nhớ của bạn đã 4 GBđược sử dụng hết và RAM trông như thế này:
Vấn đề 1: Bây giờ bạn không thể bắt đầu bất kỳ quá trình nào khác, vì tất cả RAM đã được sử dụng hết. Vì vậy, các chương trình phải được viết để giữ bộ nhớ tối đa có sẵn (thực tế thậm chí sẽ ít hơn, vì các phần mềm khác cũng sẽ chạy song song!). Nói cách khác, bạn không thể chạy một ứng dụng tiêu tốn nhiều bộ nhớ trên chiếc 1 GBPC cũ nát của mình .
Được rồi, bây giờ bạn quyết định rằng bạn không cần tiếp tục mở Eclipse và Chrome nữa , bạn đóng chúng để giải phóng một số bộ nhớ. Không gian bị chiếm dụng trong RAM bởi các quá trình đó được hệ điều hành lấy lại và trông giống như sau:
Giả sử rằng việc đóng hai cái này sẽ giải phóng 700 MBkhông gian - ( 400+ 300) MB. Bây giờ bạn cần khởi chạy Opera , nó sẽ chiếm dung lượng 450 MB. Vâng, 450 MBtổng cộng bạn có nhiều hơn không gian có sẵn, nhưng ... nó không liền nhau, nó được chia thành các phần riêng lẻ, không có phần nào đủ lớn để vừa 450 MB. Vì vậy, bạn nảy ra một ý tưởng tuyệt vời, hãy chuyển tất cả các quy trình bên dưới lên càng nhiều càng tốt, điều này sẽ để lại 700 MBkhoảng trống ở một đoạn ở phía dưới. Đây được gọi làcompaction. Tuyệt vời, ngoại trừ điều đó ... tất cả các quy trình ở đó đang chạy. Di chuyển chúng sẽ có nghĩa là di chuyển địa chỉ của tất cả nội dung của chúng (hãy nhớ rằng, OS duy trì ánh xạ của bộ nhớ được phần mềm mở ra đến địa chỉ bộ nhớ thực. Hãy tưởng tượng phần mềm đã lấy ra một địa chỉ của 45dữ liệu 123và OS đã lưu trữ nó ở vị trí 2012và tạo một mục trong bản đồ, ánh xạ 45tới 2012. Nếu phần mềm bây giờ được di chuyển trong bộ nhớ, thì những gì từng ở vị trí 2012sẽ không còn ở đó nữa 2012, mà ở một vị trí mới và OS phải cập nhật bản đồ tương ứng để ánh xạ 45tới địa chỉ mới để phần mềm có thể nhận được dữ liệu mong đợi ( 123) khi nó truy vấn vị trí bộ nhớ 45. Về phần mềm, tất cả những gì nó biết là địa chỉ đó45chứa dữ liệu 123!)! Hãy tưởng tượng một quá trình đang tham chiếu đến một biến cục bộ i. Vào thời điểm nó được truy cập lại, địa chỉ của nó đã thay đổi và nó sẽ không thể tìm thấy nó nữa. Điều tương tự sẽ áp dụng cho tất cả các hàm, đối tượng, biến, về cơ bản mọi thứ đều có địa chỉ và việc di chuyển một quy trình sẽ có nghĩa là thay đổi địa chỉ của tất cả chúng. Dẫn chúng ta đến:
Vấn đề 2: Bạn không thể di chuyển một tiến trình. Giá trị của tất cả các biến, hàm và đối tượng trong quy trình đó đều có giá trị được mã hóa cứng do trình biên dịch loại ra trong quá trình biên dịch, quy trình phụ thuộc vào việc chúng ở cùng một vị trí trong suốt thời gian tồn tại của nó và việc thay đổi chúng rất tốn kém. Do đó, các quy trình để lại dấu "" lớn holeskhi chúng thoát ra. Đây được gọi là
External Fragmentation.
Khỏe. Giả sử bằng cách nào đó, bằng một cách kỳ diệu nào đó, bạn quản lý để chuyển các quy trình lên. Bây giờ có 700 MBkhông gian trống ở dưới cùng:
Opera êm ái nằm ở phía dưới. Bây giờ RAM của bạn trông như thế này:
Tốt. Mọi thứ đều ổn. Tuy nhiên, không còn nhiều dung lượng và bây giờ bạn cần khởi chạy lại Chrome , một bộ nhớ đã biết! Nó cần rất nhiều bộ nhớ để bắt đầu, và bạn hầu như không còn lại ... Ngoại trừ .. bây giờ bạn nhận thấy rằng một số tiến trình, ban đầu chiếm không gian lớn, bây giờ không cần nhiều dung lượng. Có thể bạn đã dừng video của mình trong VLC , do đó nó vẫn chiếm một số dung lượng, nhưng không nhiều như yêu cầu khi chạy video có độ phân giải cao. Tương tự đối với Notepad và Photos . RAM của bạn bây giờ trông như thế này:
Holes, một lần nữa! Làm lại từ đầu! Ngoại trừ, trước đây, các lỗ hổng xảy ra do các quy trình kết thúc, bây giờ là do các quy trình yêu cầu ít không gian hơn trước! Và bạn lại gặp phải vấn đề tương tự, holeskết hợp mang lại nhiều không gian hơn yêu cầu, nhưng chúng nằm rải rác xung quanh, không được sử dụng nhiều một cách tách biệt. Vì vậy, bạn phải di chuyển các quy trình đó một lần nữa, một hoạt động tốn kém và rất thường xuyên tại đó, vì các quy trình sẽ thường xuyên giảm kích thước trong suốt thời gian tồn tại của chúng.
Vấn đề 3: Các quy trình, trong suốt thời gian tồn tại của chúng, có thể giảm kích thước, để lại không gian không sử dụng, nếu cần sử dụng, sẽ đòi hỏi hoạt động tốn kém khi di chuyển nhiều quy trình. Đây được gọi là
Internal Fragmentation.
Tốt thôi, vì vậy bây giờ, hệ điều hành của bạn thực hiện những việc cần thiết, di chuyển các quy trình xung quanh và khởi động Chrome và sau một thời gian, RAM của bạn trông giống như sau:
Mát mẻ. Bây giờ, giả sử bạn tiếp tục xem Avatar trong VLC . Yêu cầu bộ nhớ của nó sẽ tăng lên! Nhưng ... không còn không gian để nó phát triển nữa, vì Notepad đã bị thu gọn lại ở phía dưới của nó. Vì vậy, một lần nữa, tất cả các quy trình phải di chuyển bên dưới cho đến khi VLC tìm thấy đủ dung lượng!
Vấn đề 4: Nếu các quy trình cần phát triển, đó sẽ là một hoạt động rất tốn kém
Khỏe. Bây giờ, giả sử, Ảnh đang được sử dụng để tải một số ảnh từ đĩa cứng ngoài. Việc truy cập vào đĩa cứng sẽ đưa bạn từ lĩnh vực của bộ nhớ đệm và RAM sang của đĩa, tốc độ này chậm hơn theo thứ tự độ lớn. Đau đớn, không thể thay đổi, chậm hơn siêu việt. Đây là một hoạt động I / O, có nghĩa là nó không bị ràng buộc bởi CPU (hoàn toàn ngược lại), có nghĩa là nó không cần chiếm RAM ngay bây giờ. Tuy nhiên, nó vẫn chiếm RAM một cách cứng đầu. Nếu bạn muốn khởi chạy Firefox trong thời gian chờ đợi, bạn không thể, vì không còn nhiều bộ nhớ, trong khi nếu Ảnh bị lấy ra khỏi bộ nhớ trong thời gian hoạt động liên kết I / O của nó, nó sẽ giải phóng rất nhiều bộ nhớ, tiếp theo là compaction (đắt tiền), tiếp theo là Firefox phù hợp.
Vấn đề 5: Các công việc ràng buộc I / O tiếp tục chiếm RAM, dẫn đến việc sử dụng thiếu RAM, có thể đã được sử dụng bởi các công việc ràng buộc CPU trong thời gian chờ đợi.
Vì vậy, như chúng ta có thể thấy, chúng ta gặp rất nhiều vấn đề ngay cả với cách tiếp cận của bộ nhớ ảo.
Có hai cách tiếp cận để giải quyết những vấn đề này - pagingvà segmentation. Hãy để chúng tôi thảo luận paging. Trong cách tiếp cận này, không gian địa chỉ ảo của một tiến trình được ánh xạ tới bộ nhớ vật lý theo từng phần - được gọi là pages. Một pagekích thước điển hình là 4 kB. Ánh xạ được duy trì bởi một cái gì đó được gọi là a page table, cho một địa chỉ ảo, tất cả những gì chúng ta phải làm bây giờ là tìm ra pageđịa chỉ thuộc về, sau đó từ đó page tabletìm vị trí tương ứng cho địa chỉ đó pagetrong bộ nhớ vật lý thực tế (được gọi là frame), và cho rằng độ lệch của địa chỉ ảo bên trong pagelà giống nhau đối pagevới cũng như frame, tìm ra địa chỉ thực bằng cách thêm độ lệch đó vào địa chỉ được trả về bởi page table. Ví dụ:
Ở bên trái là không gian địa chỉ ảo của một tiến trình. Giả sử không gian địa chỉ ảo yêu cầu 40 đơn vị bộ nhớ. Nếu không gian địa chỉ vật lý (bên phải) cũng có 40 đơn vị bộ nhớ, thì có thể ánh xạ tất cả vị trí từ bên trái sang vị trí ở bên phải, và chúng tôi sẽ rất vui. Nhưng may mắn thay, bộ nhớ vật lý không chỉ có sẵn ít đơn vị bộ nhớ hơn (24 ở đây) mà nó còn phải được chia sẻ giữa nhiều quá trình! Tốt thôi, hãy xem chúng ta làm như thế nào với nó.
Khi quá trình bắt đầu, giả sử yêu cầu truy cập bộ nhớ cho vị trí 35được thực hiện. Ở đây kích thước trang là 8(mỗi trang pagechứa các 8vị trí, toàn bộ không gian địa chỉ ảo của các 40vị trí do đó chứa 5các trang). Vì vậy, vị trí này thuộc về trang số. 4( 35/8). Trong phạm vi này page, vị trí này có phần bù của 3( 35%8). Vì vậy, vị trí này có thể được chỉ định bởi tuple (pageIndex, offset)= (4,3). Đây chỉ là bước khởi đầu, vì vậy chưa có phần nào của quá trình được lưu trữ trong bộ nhớ vật lý thực tế. Vì vậy page table, duy trì ánh xạ các trang ở bên trái sang các trang thực tế ở bên phải (nơi chúng được gọi làframes) hiện đang trống. Vì vậy, hệ điều hành từ bỏ CPU, cho phép trình điều khiển thiết bị truy cập vào đĩa và tìm nạp trang số. 4cho quá trình này (về cơ bản một đoạn bộ nhớ từ chương trình trên đĩa có địa chỉ dao động từ 32để 39). Khi nó đến, OS sẽ phân bổ trang ở đâu đó trong RAM, chẳng hạn như chính khung hình đầu tiên, và page tablequá trình này lưu ý rằng trang đó 4ánh xạ đến khung 0trong RAM. Bây giờ dữ liệu cuối cùng đã có trong bộ nhớ vật lý. OS lại truy vấn bảng trang cho bộ tuple (4,3), và lần này, bảng trang cho biết trang đó 4đã được ánh xạ tới khung 0trong RAM. Vì vậy, OS chỉ đơn giản là đi đến 0khung thứ trong RAM, truy cập dữ liệu tại vị trí bù 3trong khung đó (Hãy dành một chút thời gian để hiểu điều này. Toàn bộpage, đã được tìm nạp từ đĩa, được chuyển đến frame. Vì vậy, bất kể độ lệch của một vị trí bộ nhớ riêng lẻ trong một trang là gì, nó cũng sẽ giống nhau trong khung, vì bên trong page/ frame, đơn vị bộ nhớ vẫn nằm ở cùng một vị trí tương đối!), Và trả về dữ liệu! Bởi vì dữ liệu không được tìm thấy trong bộ nhớ ngay từ đầu khi truy vấn chính nó, mà thay vào đó phải được tìm nạp từ đĩa để tải vào bộ nhớ, nó tạo thành một lỗi .
Khỏe. Bây giờ, giả sử, một truy cập bộ nhớ cho vị trí 28được thực hiện. Nó sôi lên (3,4). Page tablengay bây giờ chỉ có một mục nhập, ánh xạ trang 4vào khung 0. Vì vậy, đây lại là một sự thiếu sót , quá trình rời khỏi CPU, trình điều khiển thiết bị tìm nạp trang từ đĩa, quá trình lấy lại quyền kiểm soát CPU một lần nữa và nó page tableđược cập nhật. Giả sử bây giờ trang 3được ánh xạ tới khung 1trong RAM. Vì vậy, (3,4)trở thành (1,4), và các dữ liệu tại vị trí đó trong RAM được trả về. Tốt. Theo cách này, giả sử lần truy cập bộ nhớ tiếp theo dành cho vị trí 8, được dịch sang (1,0). Trang 1chưa có trong bộ nhớ, quy trình tương tự được lặp lại và pageđược cấp phát tại khung2trong RAM. Bây giờ ánh xạ quá trình RAM trông giống như hình trên. Tại thời điểm này, RAM, chỉ có 24 đơn vị bộ nhớ khả dụng, được lấp đầy. Giả sử yêu cầu truy cập bộ nhớ tiếp theo cho quá trình này là từ địa chỉ 30. Nó ánh xạ tới (3,6)và page tablecho biết trang đó 3nằm trong RAM và nó ánh xạ vào khung 1. Yay! Vì vậy, dữ liệu được tìm nạp từ vị trí RAM (1,6)và được trả về. Điều này tạo nên một cú hích , vì dữ liệu yêu cầu có thể được lấy trực tiếp từ RAM, do đó rất nhanh. Tương tự như vậy, các yêu cầu truy cập vài hôm sau, nói cho các địa điểm 11, 32, 26, 27tất cả đều là hit , tức là dữ liệu theo yêu cầu của quá trình này được tìm thấy trực tiếp trong RAM mà không cần phải tìm nơi khác.
Bây giờ, giả sử một yêu cầu truy cập bộ nhớ cho vị trí 3xuất hiện. Nó chuyển đến (0,3), và page tablecho quá trình này, mà hiện nay có 3 mục, cho các trang 1, 3và 4nói rằng trang này không có trong bộ nhớ. Giống như các trường hợp trước, nó được tìm nạp từ đĩa, tuy nhiên, không giống như các trường hợp trước, RAM bị lấp đầy! Vậy phải làm gì bây giờ? Đây là vẻ đẹp của bộ nhớ ảo, một khung hình từ RAM bị loại bỏ! (Các yếu tố khác nhau chi phối khung nào sẽ bị loại bỏ. Nó có thể LRUdựa vào nơi mà khung được truy cập ít nhất gần đây nhất cho một quy trình sẽ bị loại bỏ. Nó có thể là first-come-first-evictedcơ sở, nơi khung được phân bổ lâu nhất trước đây, bị loại bỏ, v.v. .) Vì vậy, một số khung được loại bỏ. Nói khung 1 (chỉ chọn ngẫu nhiên nó). Tuy nhiên, điều đó frameđược ánh xạ tới một sốpage! (Hiện tại, nó được bảng trang ánh xạ tới trang 3của một quá trình duy nhất của chúng tôi). Vì vậy, quá trình đó phải được thông báo tin tức bi thảm này, rằng một trong những frameđiều không may thuộc về bạn, sẽ bị loại bỏ khỏi RAM để nhường chỗ cho cái khác pages. Quy trình phải đảm bảo rằng nó cập nhật page tablethông tin này, tức là xóa mục nhập cho bộ đôi khung trang đó, để lần sau khi yêu cầu được thực hiện cho điều đó page, nó sẽ thông báo cho quy trình biết rằng mục này pagekhông còn trong bộ nhớ và phải được tìm nạp từ đĩa. Tốt. Vì vậy, khung 1bị loại bỏ, trang 0được đưa vào và đặt ở đó trong RAM, và mục nhập cho trang 3bị xóa và thay thế bằng 0ánh xạ trang đến cùng một khung1. Vì vậy, bây giờ ánh xạ của chúng tôi trông giống như sau (lưu ý sự thay đổi màu sắc trong thứ hai frameở phía bên phải):
Thấy chuyện gì vừa xảy ra? Quá trình phải phát triển, nó cần nhiều dung lượng hơn so với RAM có sẵn, nhưng không giống như kịch bản trước đó của chúng tôi, nơi mọi tiến trình trong RAM phải di chuyển để thích ứng với một quá trình đang phát triển, ở đây nó xảy ra chỉ bằng một lần pagethay thế! Điều này được thực hiện bởi thực tế là bộ nhớ cho một tiến trình không còn cần phải tiếp giáp với nhau, nó có thể nằm ở các vị trí khác nhau theo từng phần, hệ điều hành duy trì thông tin về vị trí của chúng và khi được yêu cầu, chúng được truy vấn một cách thích hợp. Lưu ý: bạn có thể đang nghĩ, huh, điều gì sẽ xảy ra nếu hầu hết các trường hợp là a miss, và dữ liệu phải được tải liên tục từ đĩa vào bộ nhớ? Có, về mặt lý thuyết, điều đó là có thể, nhưng hầu hết các trình biên dịch được thiết kế theo cáchlocality of reference, tức là nếu dữ liệu từ một số vị trí bộ nhớ được sử dụng, thì dữ liệu tiếp theo cần thiết sẽ nằm ở một nơi nào đó rất gần, có thể là từ cùng một vị pagetrí pagevừa được tải vào bộ nhớ. Do đó, lần bỏ lỡ tiếp theo sẽ xảy ra sau một thời gian, hầu hết các yêu cầu bộ nhớ sắp tới sẽ được đáp ứng bởi trang vừa được đưa vào hoặc các trang đã có trong bộ nhớ được sử dụng gần đây. Nguyên tắc tương tự chính xác cho phép chúng ta loại bỏ những thứ ít được sử dụng nhất gần đây page, với logic rằng những gì đã không được sử dụng trong một thời gian, sẽ không được sử dụng trong một thời gian nữa. Tuy nhiên, không phải lúc nào cũng vậy, và trong những trường hợp ngoại lệ, có, hiệu suất có thể bị ảnh hưởng. Thông tin thêm về nó sau.
Giải pháp cho vấn đề 4: Các quy trình hiện có thể dễ dàng phát triển, nếu gặp phải vấn đề về không gian, tất cả những gì nó yêu cầu là thực hiện pagethay thế đơn giản mà không cần di chuyển bất kỳ quy trình nào khác.
Giải pháp cho vấn đề 1: Một tiến trình có thể truy cập bộ nhớ không giới hạn. Khi cần nhiều bộ nhớ hơn khả năng sẵn có, đĩa được sử dụng làm bản sao lưu, dữ liệu mới cần thiết được tải vào bộ nhớ từ đĩa và dữ liệu frame(hoặc page) ít được sử dụng gần đây nhất sẽ được chuyển sang đĩa. Điều này có thể diễn ra vô hạn, và vì dung lượng đĩa rẻ và hầu như không giới hạn, nó tạo ra ảo tưởng về bộ nhớ không giới hạn. Một lý do khác cho cái tên Virtual Memory, nó khiến bạn ảo tưởng về trí nhớ không thực sự có sẵn!
Mát mẻ. Trước đó, chúng tôi đã phải đối mặt với một vấn đề là mặc dù một quy trình giảm kích thước, nhưng không gian trống rất khó lấy lại bởi các quy trình khác (vì nó sẽ yêu cầu nén tốn kém). Bây giờ thật dễ dàng, khi một quy trình trở nên có kích thước nhỏ hơn, nhiều quy trình pageskhông còn được sử dụng nữa, vì vậy khi các quy trình khác cần nhiều bộ nhớ hơn, LRUviệc loại bỏ dựa trên đơn giản sẽ tự động loại bỏ những quy trình ít được sử dụng pageskhỏi RAM và thay thế chúng bằng các trang mới từ các quy trình khác (và tất nhiên là cập nhật page tablestất cả các quy trình đó cũng như quy trình gốc hiện yêu cầu ít dung lượng hơn), tất cả những quy trình này mà không có bất kỳ thao tác nén tốn kém nào!
Giải pháp cho vấn đề 3: Bất cứ khi nào các quy trình giảm kích thước, framesRAM trong RAM của nó sẽ ít được sử dụng hơn, do đó, LRUviệc loại bỏ dựa trên đơn giản có thể loại bỏ các trang đó và thay thế chúng pagesbằng các quy trình mới yêu cầu, do đó tránh được Internal Fragmentationmà không cần thiết compaction.
Còn vấn đề 2, bạn hãy dành một chút thời gian để hiểu điều này, bản thân kịch bản đã hoàn toàn bị loại bỏ! Không cần phải di chuyển một quy trình để phù hợp với một quy trình mới, bởi vì giờ đây toàn bộ quy trình không bao giờ cần phải phù hợp cùng một lúc, chỉ một số trang nhất định của nó cần phù hợp đặc biệt, điều đó xảy ra bằng cách loại bỏ frameskhỏi RAM. Mọi thứ xảy ra theo đơn vị pages, do đó không có khái niệm về holebây giờ, và do đó không có câu hỏi về bất cứ điều gì chuyển động! Có thể 10 người pagesđã phải di chuyển vì yêu cầu mới này, có hàng nghìn trong số pagesđó vẫn chưa được động đến. Trong khi đó, trước đó, tất cả các quy trình (từng bit của chúng) phải được di chuyển!
Giải pháp cho vấn đề 2: Để phù hợp với một quy trình mới, dữ liệu chỉ từ các phần ít được sử dụng gần đây của các quy trình khác phải được loại bỏ theo yêu cầu và điều này xảy ra trong các đơn vị kích thước cố định được gọi pages. Do đó không có khả năng xảy ra holehoặc External Fragmentationvới hệ thống này.
Giờ đây, khi tiến trình cần thực hiện một số thao tác I / O, nó có thể hủy CPU một cách dễ dàng! Hệ điều hành chỉ đơn giản là loại bỏ tất cả pageskhỏi RAM (có thể lưu trữ nó trong một số bộ nhớ cache) trong khi các tiến trình mới chiếm RAM trong thời gian chờ đợi. Khi hoạt động I / O được thực hiện, OS chỉ cần khôi phục các quy trình đó pagesvào RAM (tất nhiên bằng cách thay thế pagestừ một số quy trình khác, có thể từ quy trình thay thế quy trình ban đầu hoặc có thể từ một số quy trình mà bản thân chúng cần thực hiện I / O bây giờ, và do đó có thể xóa bỏ ký ức!)
Giải pháp cho vấn đề 5: Khi một tiến trình đang thực hiện các hoạt động I / O, nó có thể dễ dàng từ bỏ việc sử dụng RAM, có thể được sử dụng bởi các tiến trình khác. Điều này dẫn đến việc sử dụng RAM đúng cách.
Và tất nhiên, bây giờ không có tiến trình nào đang truy cập trực tiếp vào RAM. Mỗi tiến trình đang truy cập một vị trí bộ nhớ ảo, được ánh xạ tới một địa chỉ RAM vật lý và được duy trì bởi page-tabletiến trình đó. Ánh xạ được hỗ trợ bởi OS, OS cho phép tiến trình biết khung nào trống để có thể trang bị một trang mới cho quy trình ở đó. Vì việc cấp phát bộ nhớ này được giám sát bởi chính hệ điều hành, nó có thể dễ dàng đảm bảo rằng không có quá trình nào xâm phạm nội dung của quá trình khác bằng cách chỉ cấp phát các khung trống từ RAM hoặc khi xâm phạm nội dung của quá trình khác trong RAM, giao tiếp với quá trình để cập nhật nó page-table.
Giải pháp cho vấn đề ban đầu: Không có khả năng một quá trình truy cập nội dung của một quá trình khác, vì toàn bộ phân bổ được quản lý bởi chính hệ điều hành và mọi quá trình chạy trong không gian địa chỉ ảo hộp cát của riêng nó.
Vì vậy, paging(trong số các kỹ thuật khác), cùng với bộ nhớ ảo, là thứ cung cấp năng lượng cho các phần mềm ngày nay chạy trên hệ điều hành! Điều này giải phóng nhà phát triển phần mềm khỏi lo lắng về dung lượng bộ nhớ còn trống trên thiết bị của người dùng, nơi lưu trữ dữ liệu, cách ngăn các quy trình khác làm hỏng dữ liệu phần mềm của họ, v.v. Tuy nhiên, tất nhiên, nó không phải là bằng chứng đầy đủ. Có những sai sót:
Pagingcuối cùng, tạo cho người dùng ảo tưởng về bộ nhớ vô hạn bằng cách sử dụng đĩa làm bản sao lưu thứ cấp. Việc truy xuất dữ liệu từ bộ nhớ thứ cấp để lắp vào bộ nhớ (được gọi page swapvà trường hợp không tìm thấy trang mong muốn trong RAM được gọi page fault) là tốn kém vì nó là một hoạt động IO. Điều này làm chậm quá trình. Nhiều lần hoán đổi trang như vậy xảy ra liên tiếp và quá trình này trở nên chậm chạp một cách đáng kinh ngạc. Bạn đã bao giờ thấy phần mềm của mình đang hoạt động tốt và đẹp đẽ, và đột nhiên nó trở nên chậm đến mức gần như bị treo hoặc khiến bạn không có tùy chọn nào để khởi động lại nó? Có thể có quá nhiều lần hoán đổi trang đã xảy ra, khiến trang bị chậm (được gọi thrashing).
Vì vậy, trở lại OP,
Tại sao chúng ta cần bộ nhớ ảo để thực hiện một quá trình? - Như câu trả lời đã giải thích ở mức độ dài, để cho phần mềm ảo tưởng rằng thiết bị / Hệ điều hành có bộ nhớ vô hạn, để bất kỳ phần mềm nào, dù lớn hay nhỏ, đều có thể chạy mà không phải lo lắng về việc cấp phát bộ nhớ hoặc các quy trình khác làm hỏng dữ liệu của nó, ngay cả khi chạy song song. Nó là một khái niệm, được triển khai trong thực tế thông qua các kỹ thuật khác nhau, một trong số đó, như được mô tả ở đây, là Phân trang . Nó cũng có thể là Phân đoạn .
Bộ nhớ ảo này sẽ đứng ở đâu khi tiến trình (chương trình) từ ổ cứng gắn ngoài được đưa đến bộ nhớ chính (bộ nhớ vật lý) để thực thi? - Bộ nhớ ảo không đứng ở bất kỳ đâu, nó là một phần trừu tượng, luôn hiện hữu, khi phần mềm / quy trình / chương trình được khởi động, một bảng trang mới được tạo cho nó và nó chứa ánh xạ từ các địa chỉ được tạo ra bởi đó xử lý đến địa chỉ vật lý thực tế trong RAM. Vì các địa chỉ được quy trình phun ra không phải là địa chỉ thực, theo một nghĩa nào đó, chúng thực sự là những gì bạn có thể nói the virtual memory,.
Ai chăm sóc bộ nhớ ảo và kích thước của bộ nhớ ảo là bao nhiêu? - Nó được chăm sóc song song bởi hệ điều hành và phần mềm. Hãy tưởng tượng một hàm trong mã của bạn (cuối cùng được biên dịch và tạo thành tệp thực thi tạo ra quá trình) chứa một biến cục bộ - an int i. Khi mã thực thi, inhận được một địa chỉ bộ nhớ trong ngăn xếp của hàm. Hàm đó chính nó được lưu trữ như một đối tượng ở một nơi khác. Các địa chỉ này được tạo bởi trình biên dịch (trình biên dịch đã biên dịch mã của bạn thành tệp thực thi) - địa chỉ ảo. Khi được thực thi, ít nhất iphải cư trú ở một nơi nào đó trong địa chỉ vật lý thực tế trong khoảng thời gian của hàm đó (trừ khi nó là một biến tĩnh!), Vì vậy OS ánh xạ địa chỉ ảo của trình biên dịch tạo raithành một địa chỉ vật lý thực tế, để bất cứ khi nào, trong hàm đó, một số mã yêu cầu giá trị của i, quá trình đó có thể truy vấn hệ điều hành về địa chỉ ảo đó và đến lượt nó, hệ điều hành có thể truy vấn địa chỉ vật lý cho giá trị được lưu trữ và trả lại.
Giả sử nếu kích thước của RAM là 4GB (tức là 2 ^ 32-1 không gian địa chỉ) thì kích thước của bộ nhớ ảo là bao nhiêu? - Kích thước của RAM không liên quan đến kích thước của bộ nhớ ảo, nó phụ thuộc vào hệ điều hành. Ví dụ, trên Windows 32 bit, nó là 16 TB, trên Windows 64 bit, nó là 256 TB. Tất nhiên, nó cũng bị giới hạn bởi kích thước đĩa, vì đó là nơi bộ nhớ được sao lưu.