과제/LG/2013/황세영 분석자료
Retired DISLab
(→2014-07-14) |
(→2014-07-14) |
||
| 159번째 줄: | 159번째 줄: | ||
*[[media: 페이지교체알고리즘_140714.docx | 페이지 교체 알고리즘(docx)]] / [[media: 페이지교체알고리즘_140714.pdf | 페이지 교체 알고리즘(pdf)]] | *[[media: 페이지교체알고리즘_140714.docx | 페이지 교체 알고리즘(docx)]] / [[media: 페이지교체알고리즘_140714.pdf | 페이지 교체 알고리즘(pdf)]] | ||
*[[media: open과정_140714.hwp | Open 과정(hwp)]] / [[media: open과정_140714.pdf | Open 과정(pdf)]] | *[[media: open과정_140714.hwp | Open 과정(hwp)]] / [[media: open과정_140714.pdf | Open 과정(pdf)]] | ||
| + | |||
| + | ==== 2014-07-15 ==== | ||
| + | *[[media: 리눅스 커널 문서_140715.docx | 리눅스 커널 문서(docx)]] / [[media: 리눅스 커널 문서_140715.pdf | 리눅스 커널 문서(pdf)]] | ||
| + | ** 2014-07-14의 모든 내용을 포함하고, Write부분과 페이지 교체 알고리즘의 내용 등이 수정된 문서 | ||
2014년 7월 15일 (화) 09:03 현재 판
 |
교수가 콤멘트하는 것은 형광색으로 표기 |
목차 |
황세영
2014-03-31
날짜별로 절로 표기해야 수정하기 좋단다. 이처럼 절로 표기하거라.
- 컴공과세미나자료(zip)
- 리눅스커널READ부분(hwp) / 리눅스커널READ부분(pdf) - PDF로 올려야 읽을 수 있다.
- 컴공과세미나자료의 '리눅스 커널 구조 분석' 자료에 나온 READ부분 함수를 모두 정리해둔 것
- 각 함수의 시작 바로 전 괄호는 커널에서의 위치를 나타냄
- vfs_read (소스 테스트)
// Virtual File System // fs/read_write.c ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos){ ssize_t ret; if (!(file->f_mode & FMODE_READ)) return -EBADF; if (!file->f_op || (!file->f_op->read && !file->f_op->aio_read)) return -EINVAL; if (unlikely(!access_ok(VERIFY_WRITE, buf, count))) return -EFAULT; ret = rw_verify_area(READ, file, pos, count); if (ret >= 0) { count = ret; if (file->f_op->read) // read에 해당하는 'ext4 파일 연산 함수 테이블'의 함수는 do_sync_read ret = file->f_op->read(file, buf, count, pos); else ret = do_sync_read(file, buf, count, pos); if (ret > 0) { fsnotify_access(file); add_rchar(current, ret); } inc_syscr(current); } return ret; }
2014-04-02
- The Virtual Filesystem (가상 파일시스템)
- =Virtual File Switch, VFS
- 리눅스는 가상 파일시스템을 사용하여 다양한 디스크 유형을 지원
- 커널의 서브시스템으로, 표준 유닉스 파일시스템과 관련한 모든 시스템 콜을 처리하는 커널 소프트웨어 계층
- 모든 파일시스템들은 VFS을 필요로 하며, VFS는 여러 종류의 파일시스템에 대해 공통 인터페이스를 제공
- 지원하는 모든 파일시스템을 표현할 수 있는 공통 파일 모델 도입
- 각각에 해당하는 특정 파일시스템을 구현할 때는 반드시 자신의 물리적인 구성을 VFS의 공통 파일 모델로 변환해야 함
- 예를들어 파일은 커널 메모리에서 file로 자료 구조를 표현함. file 내부에는 f_op라는 함수 포인터가 있고, 그 중 read가 있으며, 파일 시스템의 실제 함수에 대한 포인터에 해당함.
- 따라서 file->f_op->read(..)와 같은 형태로 모든 파일 시스템에 대한 read 함수를 호출 가능.
- 위와 같은 공통 파일 모델(file)은 객체 지향적인 방식을 사용했지만, 성능 향상을 위해 객체 지향 언어를 사용하지 않음.
- 구조체에 변수와 함수 구조체에 대한 포인터를 둠. 일반적으로 함수 구조체에 대한 포인터는 'op'로 표현
- 함수 구조체는 실제 구현되어 있는 함수로 연결됨.
- 예를들어 ext4 파일 시스템에서 file->f_op->read(..)는 실제로는 do_sync_read함수를 호출
- VFS는 독자적으로 저수준 프로시저를 호출하지 않고 파일 연산을 실행할 수 있음. 따라서 필요하다면 특정 파일시스템에 의존하는 '일반' 파일시스템으로 볼 수도 있음
- 예를들어 프로세스가 열린 파일을 닫으려 할 때는 디스크 파일을 건드리지 않고 VFS에 대응하는 파일 객체를 해제함
- 공통 파일 모델(file)
- 공통 파일 모델은 수퍼블록 객체, 아이노드 객체, 파일 객체, 디엔트리 객체로 나뉨
- 수퍼블록 객체 : 마운트시킨 파일시스템 정보를 저장하며 file 구조체에서 필드명은 대부분 's_'로 시작.
- 아이노드 객체 : 특정 파일에 대한 일반 정보를 저장. 아이노드 번호는 파일시스템 내 각 파일을 유일하게 식별함. file 구조체에서 필드명은 대부분 'i_'로 시작
- 파일 객체 : 열린 파일과 프로세스 사이의 상호 작용과 관련한 정보를 저장. file 구조체에서 필드명은 대부분 'f_'로 시작
- 디엔트리 객체 : 디렉토리 항목과 대응하는 파일간 연결에 대한 정보를 저장. file 구조체에서 필드명은 'd_'로 시작
- 리눅스커널READ부분_위치정리(xlsx)
- 2014-03-31에 올린 '리눅스커널READ부분'에서 함수의 위치만 정리한 액셀 파일
- SYSCALL_DEFINE3_분석(pdf)
2014-04-07
- 140407_커널분석(pdf)
- vfs_read부터 generic_make_request 까지
- bio 구조와 requst queue의 구조 및 이들의 동작방법을 자세히 파악하는 것이 중요하다. 꼼꼼히 코드를 읽어보기 바란다.
- vfs_read부터 generic_make_request 까지
2014-04-16
- 140416_커널분석(pdf)
- blk_init_queue부터 __blk_run_queue_uncond 까지
- 이하 bio 구조와 request queue의 구조 및 이들의 동작방법을 파악하는 것이 중요하다고 하셔서 블록 장치의 동작 방식에 대한 정리를 추가합니다.
- 위의 커널분석은 이 내용을 따로 정리하기 전에 적어둔 것이라 포함되어 있지 않습니다. 다음 번에 올릴 때 이 내용도 추가해 두겠습니다.
- 블록 장치 : 일정 크기(블록) 단위로 접근하는 장치로 대표적인 예로 하드 디스크
- 블록 장치는 파일 시스템에 의해 간접적으로 접근하게 되어 있으며 VFS에 의해 어떤 파일 시스템이라도 관계없이 같은 방식으로 이용
- 블록IO의 시작 지점은 submit_bio()로, 인자로 READ or WRITE와 bio 구조체를 받음.
- READ : 디스크에 저장된 데이터를 메모리로 옮김, WRITE : 메모리에 저장된 데이터를 디스크로 옮김
- bio는 해당 연산에 대한 모든 정보를 포함하는 구조체로써, IO를 수행할 디스크 영역의 정보와 IO를 수행할 메모리 영역의 정보를 포함
- 현재 bio는 세그먼트를 bio_vec 구조체를 통해 저장
- 세그먼트는 기본적으로 페이지의 형태로 저장되므로 이에 대한 모든 정보가 포함하며 장치가 한 IO당 여러 세그먼트를 지원할 수 있으므로 이를 벡터(배열) 형태로 저장
- BIO 구조체 하나가 BIO_VEC 구조체를 배열로 관리하며 여러곳에 흩어진 블록들을 관리하여 IO연산을 수행 (scatter-gather I/O)
- bio구조체관계(jpg)
- bio구조체와 bio_vec구조체, 세그먼트의 관계 (출처 : http://blog.naver.com/kkn2988?Redirect=Log&logNo=141641230)
- struct bio 필드
- bi_sector : 디스크 상의 연관된 섹터 주소
- bi_next : request 큐 리스트
- bi_bdev : 연관된 블록 디바이스
- bi_flags : 상태, 명령 플래그
- bi_rw : 하위 비트는 읽기/쓰기, 상위 비트는 우선순위
- bi_vcnt : bi_io_vec 리스트 길이(개수)
- bi_idx : bi_io_vec의 현재 인덱스
- bi_phys_segments : 물리 주소를 병합한 이후의 세그먼트 개수
- bi_size : 남은 I/O 개수
- bi_seg_front_size : 합칠 수 있는 첫 세그먼트 크기
- bi_seg_back_size : 합칠 수 있는 마지막 세그먼트 크기
- bi_max_vecs : 가능한 bi_io_vec 리스트의 최대 길이
- bi_comp_cpu : 완료된 CPU
- bi_cnt : 사용 빈도수
- bi_io_vec : bi_io_vec 리스트
- bi_end_io : I/O 완료 함수포인터
- bi_private : 소유자의 사적인 메소드
- bi_destructor : 소멸자 메소드
- bi_inline_vecs[0] : 내부적으로 메모리 할당시 사용되는 bi_io_vec 배열
- struct bio_vec 필드
- bv_page : 해당 버퍼가 놓여있는 물리적인 페이지로의 포인터
- bv_len : 이 버퍼의 바이트 길이
- bv_offset : 페이지 내에서의 버퍼의 위치(바이트 오프셋)
- bio는 디스크 상에서 연속된 영역 만을 나타낼 수 있음. 따라서 접근하려는 데이터가 디스크 상에서 여러 부분으로 나뉘어 있다면 각각에 해당되는 bio가 할당되어 submit_bio()함수를 통해 각각 전달됨
- request 구조체는 블록 디바이스의 블록 IO 요청을 정의하며, request_queue는 각각의 블록 IO 요청을 담고 있음
- request_queue(jpg)
- request_queue와 request 그리고 bio의 관계 (출처 : http://blog.naver.com/kkn2988?Redirect=Log&logNo=141641230)
※
2014-04-26
2014-04-26
2014-05-02
2014-05-09
2014-05-12
- 디바이스드라이버정리(pdf)
- 이미지에 사용 struct를 추가
- SYTest, plantuml test
2014-05-15
2014-05-19
2014-05-20
140520통합자료_축약, 황세영부분)(pptx)140520통합자료_축약(건우,세영 부분)(pptx)140520통합자료_축약_v2(건우,세영 부분)(pptx)140520통합자료_축약_v3(건우,세영,희영 전체)(pptx)- 140520통합자료_축약_v4(건우,세영,희영 전체)(pptx)
2014-05-30
- Page Cache LRU 관련
- PAGE_CACHE_DIAGRAM
- Page_cache_관련함수(hwp) // Page_cache_관련함수(pdf)
- 관련사이트(현재와 맞지 않음) : [1][2]
2014-06-12
2014-07-14
- Read 과정(docx) / Read 과정(pdf)
- bio 처리 과정(docx) / bio 처리 과정(pdf)
- 페이지 교체 알고리즘(docx) / 페이지 교체 알고리즘(pdf)
- Open 과정(hwp) / Open 과정(pdf)
2014-07-15
- 리눅스 커널 문서(docx) / 리눅스 커널 문서(pdf)
- 2014-07-14의 모든 내용을 포함하고, Write부분과 페이지 교체 알고리즘의 내용 등이 수정된 문서
