SW Design의 철학.

Abstraction

1. Design abstractions to use hardware
   • Define APIs for applications to use
2. Protection & Isolation
   • Contain malicious or buggy behaviors of applications
   • Protecting OS from malicious or buggy applications
   • Isolating one application from another
3. Sharing resources
   • Multiplex hardware resources

What is “Abstraction”?

• The process or outcome of making something easier to understand by ignoring some of details that may be unimportant.

→ 추상화의 Target은 HW이다.

1. 메모리의 추상화는 가상메모리
2. 디스크의 추상화는 파일..!

OS designers’ first thought

• No one want to write programs directly handling hardware details (easy to program)
• To utilize hardware resources, OS has to run multiple applications (management unit of execution)
• Protect applications from each other (protection unit of execution)

What is the conclusion?

• Building an abstraction that gives an illusion that each application runs on a single machine
• Let’s call it process (= executed application)

How to make it easy to use hardware?

• OS designers build each abstraction of hardware resources and bind it to process
  • CPU -> Virtualizing CPU
  • Memory -> Virtual address space
  • Storage -> File
• OS designers provide APIs to applications to use the abstractions

They call them as system calls

Process

What process abstracts?

• Each process has its own view of ( Machines )
  • Own address space
  • Own virtual CPU
  • Own files

Nice clean abstraction!

The next question is how to design each abstraction?

Abstraction of address space

• How to associate virtual address to physical address?
  • Divide each physical memory to small chunk (called page)
  • Create mapping from virtual to physical address

→ 은행계좌와 실제 현물을 상관지어보면 이해가 쉽네!

테이블 블록 단위를 4KB로 한것은 이게 효율이 좋게 나왔다함.

Virtual memory: Level of Indirection

Level of indirection

가상주소와 물리주소 매핑 → Page-Tabe

Abstraction of address space

• How to map virtual to physical address?
  • Segmentation
  • Paging (Single-level, multi-level …)
  • Segmented paging

Level of Indirection happens!

MMU 칩이 알고리즘을 통해서 가상 주소를 물리 주소로 변환해줌.

DRAM이 너무 빨라서, HW fault 메커니즘이 나온겁니다. 그렇기 때문에 MMU칩을 따로 둔것입니다.

→ 1970년대 정립된 내용입니다.

Address translation: Paging

• TLB caches page table entries
  • Translation lookaside buffer
  • 페이지 테이블 생성.
• Page number: logical address
  • Virtual Memory → Physical Memory로 변경
• Frame number: physical address

Mechanism → HW (빠르고 일관된 일 수행)

Policy → SW (복잡한 로직 수행)

Mechanism vs Policy

code 안에서 Mechanism과 Policy를 분리해야합니다.

Abstraction of address space

Think about these questions

• Where is the page tables stored?
• What are role(s) of software (OS) for paging?
• What are role(s) of hardware for paging?

When to allocate physical memory?

• Demand paging
  • Application first accesses Virtual address of unallocated physical memory

→ Page fault handler and getting demanding page

Zero the page usually takes LONG time.

만약 page를 0로 설정하지 않으면, 이전에 있던 데이터를 읽을 수 있다는 뜻입니다. 따라서 Process간 protect가 되지 않습니다.

→ 그렇다면 malloc 에서는 왜 초기화를 안할까요?

→ Thread 끼리의 공유는 Process간 Protection에 위반하지 않으므로 괜찮습니다.

Zero the page file-backed and Anonymous

1. file-backed → get the file
2. Anonymous → set it 0

Page fault handling

Two types of memory: ( Code + Data and Stack + Heap )

→ file-backed and Anonymous

→ 이미 그 크기와 사이즈를 알고 있으므로.

→ mmap 은 Anonymous

Page fault handling

Processor signals controller

• Read block of length P starting at disk
  address X and store starting at memory
  address Y

Read occurs

• Direct Memory Access (DMA)
• Under control of I/O controller

I / O controller signals completion

• Interrupt processor
• OS resumes suspended process

Abstraction of storage

파일은, 저장소의 논리적 단위! → 이것도 그냥 매핑임… 파일은 존재하지 않고 디스크에 산재해 있는 데이터에 접근하는 지도가 파일임.

• File: a logical unit of storage

  • Identifier : pathname (path + filename)
  • Location of data is identified by ( offset )
  • OS subsystem maps the file to physical storage Let’s call it ( file System )

• Analogy

  • Virtual memory is an abstraction of physical memory
    • Level of indirection: ( VA ) → ( PA )
  • File is an abstraction of physical storage
    • Level of indirection: ( path , offset) → (block Address)

File System: A Mapping Problem

• <filename, data, metadata> → a set of blocks

• How to map file to storage media?
  • Divide a file to small chucks (called block)
  • Create mappings from each block to a storage location
    (called block address)

→ 어떤 자료구조를 사용해서, 언제 Mapping을 할 것인가?

Abstraction of storage

• How to create the mappings from file to storage?
  • File’s logical block -> Storage physical block

→ 파일 시스템의 디자인 (오래된)

Think about these questions!

• Where are the internal nodes in the index? (memory?
  storage? or both! )
• Does hardware help for the indexing?
  • If yes, what is role(s) of hardware?
  • If not, why?
    • (내 생각에는 HW에게 있어서 인덱싱 처리가 힘들줄 알았는데, 교수님 말씀으로는 속도차이 떄문이라함)
    • 미래에는, Storage가 DRAM처럼 빨라지면 HW로 indexing 처리를 할 수도 있음!
• When to allocate physical block?
  • 파일을 쓰고, ‘저장’ 할 때 해당 블록을 실제로 할당합니다.
  • 어떤 system call 이 불릴까?? fsync() 크러쉬 컨시스턴시…
• Any performance optimization for slow storage device?
  • DRAM caching

Storage stack overview

Think about these questions

• Why VFS is required?
  • 각 파일 시스템에 대해 호환되게 하기 위해서.
• Why Generic Block Layer is required?
  • 같은 인터페이스로 접근할 수 있음.
• Where is IO queues implemented?
  • Generic Block Layer → 디바이스에도 종속되지 않으며, 파일 시스템에도 종속되지 않은 일반적은 I/O 큐 설계를 할 수 있는 위치임.
• Where is page cache implemented?
  • VFS-POSIX API →

Page Cache