일자 : 2023. 05. 20

범위 : 리눅스 커널 내부 구조 4장 ~ 5장

참가 : 약 25명  
  
3주차 

  

3-1 Buddy와 Slab

  

Q. 책 그림 오류(p.107) : 해제 시 10번 리스트가 제외되어야 한다.

  

Q. 버디 할당자가 10KB 요청에 대해 16KB를 할당하는 이유

A. 2의 승수로 페이지 테이블을 관리하는 것이 자원 효율적 & 구현의 편리함
    

Q. 내부단편화 외부단편화의 차이점

A0. 4kb 프레임 하나 주면 꽉차니까 내부 단편화가 없음 1byte

페이지 프레임 하나에 대해 보았을때 꽉 찼는지 아닌지

외부단편화 페이지 프레임 하나로 보며 거시적으로 보았을때

페이지 프레임 1개 

사용자가 2개의 페이지 프레임 요청한다고 가정하면 

시스템에는 2개가 있어서 할당할 수 있는데

연속하지 않기 떄문에 할당할 수 없다

  
  

내부 단편화, 외부 단편화 관련.. 

[https://m.blog.naver.com/rbdi3222/220623825770](https://m.blog.naver.com/rbdi3222/220623825770) 

[https://www.mygnit.co.kr/bbs/board.php?bo_table=bo_01&wr_id=158](https://www.mygnit.co.kr/bbs/board.php?bo_table=bo_01&wr_id=158) 

  
  
  

Q. 104,106~107p 비트맵 언제 쓰는지

A0. 큰 유닛으로 머지하기 위해서 사용

자기 자신하고 XOR로 한다

내가 할당이고 버디가 할당이 아니면 1

내가 할당이고 버디가 할당이면 0

XOR를 유지하게 되면

나의 상태는 어떻게 파악하게될까

나의 상태가 0이라면 2가지가 존재

내가 free 상대도 free

나도 alloc 상대도 alloc

  

free list가 있어서 적정한 것을 찾을 수 있다.

위에서 가져온 페이지 프레임 넘버는 free상태였다 (allocate할때)

그것을 기반으로 버디를 예측할 수 있다.

내가 free니까 bitmap 상태는 1 

  

Q. free_area.free_list의 화살표 그림

A. Doubly linked list를 의미.

  

Q. 103page 리눅스 구현상 최대할당 크기는 4MB인데 CPU bit에 영향을 받을지 그렇지 않은지

A. 구현시 최대 order가 10개여서 그런것 같습니다.

A. 메모리 allocator는 여러개가 존재

  

Q. 메모리 allocator가 여러개일때 어떤 allocator를 쓰게할지 선택은 OS에서 하는지 다른 어떤 존재가 선택하게 해야하는지

A0. OS

A1. 사용자나 개발자가 선택해서 하는 것이 아닐까 생각. 사용되는 함수가 다를 수 있다.

  

Q. 그럼 유저가 일반적으로 heap에 메모리 할당시 사용하는 malloc의 경우는 어떤 allocator를 사용하는 것일까요?

A. 커널로 alloc으로 보기는 어려움. 아마 heap allocator가 사용될 것.

  
  

3-2. Lazy Buddy

  

3-3 Slab Allocator

  

Q. Slab allocator로 할당된 공간을 사용자 입장에서 free 하면 커널입장에서 공간이 free되어있는지 그렇지 않은지(사용자가 free랑 공간만큼 제어권이 slab allocator로 넘어가는지)

A0.커널 입장에서 free라고 말하기는 애매함

물리 메모리 점유는 되어 있음

사용자 입장에서는 free()를 하였음

Slab allocator =>도매상  
Slab allocator가 buddy한테 미리 일정 공간을 할당받고

그것을 쪼개서 사용자 프로그램에서 할당해서 가져다 쓸 수 있게 하는 방식  
  

Q. free로 메모리 권한이 slab allocator로 넘어간 뒤에 실제로 물리 메모리 공간에 해제되게 할려면 어떻게 해야할 수 있는지, 프로세스가 종료되어야 해제되는지 혹은 별도의 방법으로 메모리 공간을 해제할 수 있는지

A. cache처럼 저장 되며 커널이 실행되는 동안에는 해당 공간을 점유하게 됨

  
  

Q. cache처럼 되어있는데 용량을 설정할 수 있는지, kernel에 하드코딩 되어있는지

A. 통계적으로 어떤 사이즈가 나은지 확인해서 정해진 사이즈 

  
  

Q. memory allocator 개념이 사용자가 선택할 수 있는 그런 개념인거지.

A. 사용자 입장에서 malloc 등 사용하고자 하는 allocator를 선택할 수 는 있음 

  
 

 

Q. 슬랩 할당자의 기본 캐시 크기 사이즈를 최대로 변경하면 작업 처리 속도가 빨라질까?

A. 메모리 사용 효율(메모리 최적화)의 측면이기에 속도와는 큰 상관이 없을 것 같다.
A. 또한 커널 사용 측면에 따라 다를 것이기에(가령 큰 크기의 캐시를 자주 사용하는 경우) 벤치마킹 테스트가 필요할 것으로 보임.
    

4. 메모리관리 

4. 가상메모리 관리기법 

 

Q. BSS 영역을 heap 영역으로 볼 수 있을까?

 

1. BSS 영역은 초기화되지 않은 데이터 영역
    
2. heap 영역은 그 윗 부분에 저장되는 것 같다.
    
3. 그림은 아직 heap 영역을 할당하지 않은 상태로도 보인다.
    
4. 가상 메모리 구조(layout)은 마음대로 설정할 수 있지만… 일반적으로는 그림처럼 힙과 스택 영역을 할당한다. 커널 매핑의 경우에도 최근 테크닉에 따라 매핑을 하지 않기도 하다고…
   

5. 가상 메모리와 물리메모리의 연결 및 변환 

  

Q. CPU가 표현할 수 있는 주소의 범위는, 프로그램이 할당받은 가상 메모리의 크기인 3GB까지일까?

1. 32bit 프로세서인 경우 그렇다.
    

  

Q. page fault 발생 시, 운영체제가 모든 경우에 페이지 프레임을 새로 할당하는걸까?

1. 페이지 프레임을 새로 할당받는 경우와 segmentation fault, 두 가지 경우로 구분할 수 있다. 운영체제는 두 경우를 구분할 수 있어야 한다.
    
2. ELF 파일에 프로그램의 세그먼트를 물리 메모리의 어느 부분에 올리는가에 대한 정보를 가지고 있다. 이로부터 유효한 세그먼트를 판단할 수 있다.
    
3. 운영체제의 페이지 테이블 엔트리에는 해당 페이지의 접근 권한, 페이지 테이블에 접근했던 정보들이 모두 저장되어 있다. 만약 특정 virtual address에 접근하는 경우, 해당 페이지 주소가 사전에 할당이 되어있어 접근이 가능하다면 OK, 할당이 안되었거나(혹은 swap out 되었거나) 접근이 불가능한 페이지 주소라면 X. (이 경우 segmentation fault를 반환하는 것이라고 이해했다.)
    

  

Q. page table 위치

1. 각 태스크마다 page table이 마련되어 있다. memory management(mm) 구조체에 pgd 항목이 있는데, 여기서 pgd는 최상위 페이지 테이블의 주소를 의미한다. task struct 마다 page table이 할당되어 있고, 따라서 page table은 물리 메모리에 존재한다고 말할 수 있다.
    

  

Q. 커널 주소 공간에 해당하는 영역 중, 특정 하나의 프로세스가 실행될 때, 커널 영역은 항상 물리 메모리에 올라가 있을까? (커널 페이지는 프로세스 specific하지 않은걸까?)

1. 커널 페이지는 물리 메모리에 상주해야 할 것 같다.
    
2. 커널 코드는 하나이지만, 모든 프로세스가 이를 카피를 뜰 수는 없다. 프로세스마다 이를 매핑하는 방식을 결정해야 할 것.
    
3. 리눅스에선 커널 페이지들은 swap되지 않는다. swap을 처리하는 코드 자체가 swap되어버린다면? (코드를 한 번 봐야겠지만…)
    
4. Linux에서 Kernel page가 Swappable한지 구글링을 해보면, 이렇게 Non-swappable하다고 이야기하는 글들이 대부분이고, 저도 그렇게 알고 있습니다만, 최신 버전에서는 다를지, 최신 버전이 아니더라도 예외 케이스가 있을지는 잘 모르겠네요.
    

[https://stackoverflow.com/questions/4535379/do-kernel-pages-get-swapped-out](https://stackoverflow.com/questions/4535379/do-kernel-pages-get-swapped-out) (강준원님 공유 링크)

[https://stackoverflow.com/questions/27939617/is-kernel-virtual-memory-pages-are-swappable](https://stackoverflow.com/questions/27939617/is-kernel-virtual-memory-pages-are-swappable)

(이경재님 공유 링크)

  

Q. 처음에 적재하는 일부 페이지는 특정 기능을 하는 페이지인가?

1. code segment의 entry point는 반드시 매핑되어야 할 것.
    
2. damand paging이 과연 모든 아키텍처에서 도움이 될까? 처음 실행할 때 일부만 매핑하는 과정이 과연 얼마나 효과가 있을까…
    
3. User behavior에 따라 커널 정책이 달라질 수 있을 것 같다.
    
4. demand paging에서 특정 영역을 먼저 올리는 옵션이 있을 것 같다.
 

Chapter 5. 파일시스템과 가상 파일 시스템

  

5-1 파일 시스템 일반 

  

5-2 디스크 구조와 블록 관리 기법

  

5-3 FAT 파일시스템

  

Q. p.137 디렉터리 엔트리 구조체와 / p.136 그림5.6 의 맥락은 다른가?

    A. p.137 디렉터리 엔트리 = (FAT파일시스템에서) 파일이 가지고 있는 구조체 

    그림 5.6 = 파일시스템이 가지고 있는 FAT 테이블

    B. 5.7에 나와있는 디렉터리 엔트리는 그림 5.6에 있는 작은 테이블(new file name …)과 매치된다고 생각해도 무방하다. 디렉터리 엔트리의 start, starthi가 FAT의  start와 동일.

  

[https://commons.wikimedia.org/wiki/File:Fat32_structure.svg](https://commons.wikimedia.org/wiki/File:Fat32_structure.svg)

(노태현님 공유 링크)

  

Microsoft FAT Specification

 

(노태현님 공유)

  

Q. 디렉터리 엔트리 starthi? start?의 역할은?

1. FAT16, FAT32를 모두 호환하기 위해서 상위16비트(starthi) 하위16비트(start)로 구분하는 것으로 보임
    

  
  

Q. 슈퍼 블록에 inode 개수가 있나

    A.파일 시스템마다 다 있음

    [http://www.science.smith.edu/~nhowe/262/oldlabs/ext2.html](http://www.science.smith.edu/~nhowe/262/oldlabs/ext2.html)

    - s_inodes_count 및 s_blocks_count는 디스크의 inode 및 블록 수를 저장합니다. 

    - mkfs.ext2의 출력을 다시 보면 플로피 디스크의 총 블록 수는 1440이고 inode의 수는 184임을 알 수 있습니다. 

    - 또한 동일한 출력에서 ​​블록의 크기가 1024바이트임을 알 수 있습니다. 따라서 1440블록 * 1024바이트 = 1440KB, 플로피 디스크의 전체 크기입니다.

    (임채훈님 공유)

  

Q. inode indirect 구조를 3단계로 나눈이유는 더 큰 파일 을 담기 위함인가? 

A. O
  

Q. i_links_count 는 심볼릭 링크와 하드 링크 둘다 Count 하는가

A. 하드링크를 Count. i_node를 공유하는 형태이기 떄문임.
    

 

(이영재님 공유)

  
  

Q. “p.146 inode 테이블과 데이터 블록 내에서 빈 공간을 관리하기 위해 비트맵을 사용하는데, 이것이 바로 데이터 블록 비트맵과 inode비트맵이다. 이 비트맵은 무조건 한 블록내에 존재해야 한다.” 왜 한 블록내에 존재해야 하는가?

  
  

Q. 파티션마다 파일 시스템이 존재한다고 되어 있고, 

p.144 세번째 단락에 보면 Ext2로 파일 시스템을 구축하면 boot block, block groups 가 존재한다고 하는데.. 

예를 들어 하나의 하드 디스크를 3개의 파티션으로 나누고 모두 Ext2 파일 시스템을 구축하면 모든 파티션에 boot block 존재할까요??

A. 메인 파티션에 반드시 존재해야 하지만, 다른 파티션에 필수로 존재해야하는지는 의문.