Tại sao fopen/fgets sử dụng cả mmap và đọc các cuộc gọi hệ thống để truy cập dữ liệu?

Question

Tôi có một chương trình mẫu nhỏ chỉ đơn giản là fopen s tệp và sử dụng fgets để đọc. Sử dụng strace, tôi nhận thấy rằng lệnh gọi đầu tiên tới fgets chạy một cuộc gọi hệ thống mmap và sau đó đọc các cuộc gọi hệ thống được sử dụng để thực sự đọc nội dung của tệp. trên fclose, tệp là munmap ed. Nếu tôi thay vì mở đọc tập tin với mở/đọc trực tiếp, điều này rõ ràng là không xảy ra. Tôi tò mò về mục đích của mmap này là gì và mục đích của nó là gì.

Trên hệ thống dựa trên Linux 2.6.31 của tôi, khi có nhu cầu bộ nhớ ảo nặng, các đôi khi một vài giây sẽ bị treo trong một vài giây và có vẻ như không cần thiết.

Đoạn mã ví dụ:

#include <stdlib.h> 
#include <stdio.h> 
int main() 
{ 
    FILE *f; 
    if (NULL == (f=fopen("foo.txt","r"))) 
    { 
    printf ("Fail to open\n"); 
    } 
    char buf[256]; 
    fgets(buf,256,f); 
    fclose(f); 
} 

Và đây là sản phẩm có liên quan strace khi mã trên được điều hành:

open("foo.txt", O_RDONLY)    = 3 
fstat64(3, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0 
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8039000 
read(3, "foo\nbar\n\n"..., 4096)  = 9 
close(3)        = 0 
munmap(0xb8039000, 4096)    = 0 

Answer 1

Nó không phải là tập tin đó là mmap 'ed - trong trường hợp này mmap được sử dụng ẩn danh (không phải trên một tệp), có thể phân bổ bộ nhớ cho bộ đệm mà kết quả đọc sẽ sử dụng.

malloc trong thực tế, kết quả trong cuộc gọi đến mmap. Tương tự, số munmap tương ứng với cuộc gọi đến free.

Answer 2

từ những gì tôi đã đọc chức năng ánh xạ bộ nhớ rất hữu ích trong khi xử lý các tệp lớn. bây giờ định nghĩa của lớn là cái gì tôi không có ý tưởng về. nhưng có cho các tệp lớn, chúng nhanh hơn đáng kể so với các cuộc gọi i/o 'đệm'.

trong ví dụ mà bạn đã đăng tôi nghĩ rằng tệp được mở bởi hàm open() và mmap được sử dụng để cấp phát bộ nhớ hoặc cái gì khác.

từ cú pháp của hàm mmap này có thể thấy rõ:

void *mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t off);

tham số cuối cùng thứ hai có mô tả tập tin đó nên không âm. trong khi theo dõi ngăn xếp, nó là -1

Answer 3

mmap không ánh xạ tệp; thay vào đó, nó cấp phát bộ nhớ cho bộ đệm stdio FILE. Thông thường malloc sẽ không sử dụng mmap để phân phối một phân bổ nhỏ như vậy, nhưng có vẻ như việc thực hiện stdio của glibc đang sử dụng trực tiếp mmap để nhận bộ đệm. Điều này có thể đảm bảo rằng nó được canh lề trang (mặc dù posix_memalign có thể đạt được điều tương tự) và/hoặc để đảm bảo đóng tệp trả về bộ nhớ đệm cho hạt nhân. Tôi đặt câu hỏi về tính hữu ích của việc sắp xếp trang bộ đệm. Có lẽ nó cho hiệu suất, nhưng tôi không thể nhìn thấy bất kỳ cách nào nó sẽ giúp trừ khi các tập tin bù đắp bạn đang đọc từ cũng được liên kết trang, và thậm chí sau đó nó có vẻ như một tối ưu hóa vi sai đáng ngờ.