여행다니는 펭귄

영어로 과학 학술논문 쓰는법 1편 - 간단히 요약하기

핑구힝구 — Tue, 15 Mar 2022 10:49:35 +0900

영어로 과학 논문을 쓰는것은 생각보다 귀찮은 일입니다. 학술적이면서 알아듣기 쉬워야하는 문체부터 따지는 것이 매우 많죠. 이 복잡한 문제를 차근차근 풀어봅시다. 한국어인 학술논문에도 포함되는 것이니 전 한국어로 논문 쓸건데요? 하시는 분도 봐주시면 감사하겠습니다.

1. 토픽을 분류하라

첫번째 알아봐야 할 것은 어떤 Field에 내 연구가 속하느냐는 것입니다. 단순히 Biology와 같이 큰 대분류부터 시작하는 것이죠. 이 대분류를 아는것은 내가 이 논문을 어디에 투고해야 할지도 영향을 미치기 때문에 정확하게 아셔야 합니다.

필자의 친구의 경우 IEEE에 게제할 내용을 이거 Computer Science 아님? 난 컴공과지 전자과가 아닌데? 몰?루하였다가 교수님께 한 소리를 들은 바가 있습니다.

두번째 확인해야할것은 어떤 Specific Field에 내 연구가 들어가 있느냐는 것이죠. 생물학만 해도 분자생물학인지 구조생물학인지 정보생물학인지 세부 분과가 아주 다양하죠. 확인하셨으면 정식 영문 명칭도 찾아보시는 것을 추천드립니다.

논문의 세부 분야를 분류하기 어려울 경우 지도교수님께 여쭤보는것을 추천드립니다.

이를 통해 토픽을 정확하게 분류하셨으면 다음 스텝으로 넘어가야 합니다.

2. 연구에 참여한 저자의 명단을 적어라

연구를 혼자 하셨으면 그렇게 큰 문제는 아니겠지만, 지도교수님이 교신저자를 하였거나, 대학원 동료가 실험에 참가하였거나 하면 매우매우 복잡해집니다.

실험을 사소하게 도와주신 분이더라도 아에 돈을 주고 외주를 맡긴게 아니라면, 기억하여 적어놓는 편이 좋습니다. 추후 연구윤리와 관련된 문제가 생길 가능성이 큽니다. 고로 적어두고 적절히 분류하여 저자를 구분하는 것이 좋습니다.

또한 이에 해당되는 분들께 연락하여 해당 사실을 알리는 것이 좋습니다.

3. 연구를 몇 문장 이내로 요약하라

어떤 연구 방법을 사용하였는지, 무엇이 사용되었는지를 간단하게 요약해야 합니다.

즉 연구를 위해서 뭘 했는지를 (노력 이런거 말고) 아카데믹하게 요약하는 겁니다.

연구 그 자체의 내용도 중요하지만, 논문에서 제일 중요한것은 어떤 연구방법을 사용하여서 결과를 내었는지 입니다. 슬프게도 결과 자체가 너무나 중요한 논문을 쓸 가능성은 별로 없습니다.

4. 연구 데이터가 뭔지, 무엇을 얻었는지 정리하라

연구 데이터는 까먹지 않고 전부 정리하여 리스트 해 두는것이 좋습니다. 매우 필수적인 것이라서 잊지 말아야 합니다.

5. 이 연구가 중요한 이유를 한줄요약하라

예시 구문으로는 이 셋중 하나를 선택하는것이 좋습니다.

It can increase our understanding of ~

It can be used to ~ better ~

It confirms our understanding of ~

이 이외의 구문을 쓰셔도 상관없지만 영어 초보시라면 이 세마디 정도면 대부분의 요약 가능하실테니 외워두시는 것을 추천합니다.

6. Reference들을 정리하라

Reference들은 전부 APA Style로 정리되어 있어야 합니다. 여러분들 중에는 대충 레퍼런스 달때 한국 논문 다시는 분들 많은데 영어 논문을 쓰실거라면 레퍼런스도 영문으로 되어 있는것을 다시는 것을 추천합니다. 귀찮더라도 찾아보시고 다셔야 합니다.

APA Style일로 간단하게 논문을 표시해 주는 사이트 링크입니다.

APA Style Introduction // Purdue Writing Lab

The Purdue University Online Writing Lab serves writers from around the world and the Purdue University Writing Lab helps writers on Purdue's campus.

owl.purdue.edu

이를 통해 Reference를 변환하고, 이 Reference를 사용하는 이유를 간단하게 요약해 주시면 됩니다.

APA Style 표기에 대해서는 저자가 불분명한것, 웹사이트인 것 등등 여러 케이스와 함께 별도의 글로 소개해 드리겠습니다.

6단계에 따라 이를 요약하셨으면 논문의 첫 단계인 가장 기초적인 요약이 완성된 셈입니다.

파일 시스템과 DMBS

핑구힝구 — Mon, 17 Jan 2022 18:36:28 +0900

파일 시스템과 그 문제점은 무엇일까요?

파일 시스템의 경우 응용 프로그래머가 파일 시스템, 즉 자료구조에 대해 알고 있어야 데이터에 대한 접근을 구현 할 수 있습니다.

이 경우 문제가 생기는 것을 데이터 종속성과 데이터 중복성이라고 합니다.

만약 데이터의 저장 방법이나 접근 방법이 변경 될 경우 응용프로그래머는 이를 알고 다시 응용 프로그램을 수정해 주어야 합니다. ( 데이터 종속성 )

데이터가 한 시스템 내에 중복되어 저장되기도 합니다. RAID구조와 같은 것이 이렇습니다. ( 데이터 중복성 )

데이터 중복성은 한 데이터가 수정되었을때 서로 불일치하면 데이터의 일관성이 없어지며 모순이 발생하는 문제, 동일 수준의 보안 유지가 어려워 보안성이 낮아지는 문제, 하드웨어를 비효율적으로 사용하게 되어 경제성이 낮아지는 문제, 모든 데이터의 제어가 어렵기 때문에 정확성을 유지할 수 없는 무결성의 문제가 존재합니다.

다만, 단점만 있는 것은 아니고 데이터 중복성은 이점도 존재합니다. Read 연산(트랜잭션) 이 매우 빠르다는 것이고, 파일 시스템에 따라 데이터를 옮길 일이 생길 수도 있는데 이것이 최소화되며, 그 구역이 고장났을경우 복구하기가 쉽습니다.

데이터베이스란 무엇일까요?

파일 시스템에는 이점도 있으나 단점때문에 큰 데이터(서버 등)을 관리하기 어려워서 데이터베이스라는 자료구조를 사용하게 됩니다.

데이터베이스는 당연히 컴퓨터가 접근 가능한 하드웨어 데이터 집합을 의미합니다.

이는 기본적으로 통합된 데이터를 사용합니다. 통합된 데이터는 이론적으로는 중복이 없지만, 효율성 때문에 최소 데이터를 통제된 상태로 중복하는 것을 허가합니다.

데이터베이스 내에는 운영 데이터 역시 존재하는데 이는 Kernel과 같이 시스템 작동에 핵심적인 데이터를 의미합니다. I/O데이터, 임시 데이터 등은 이에 포함되지 않습니다.

또한 데이터베이스는 공용 데이터를 지원합니다. 여러 User가 한 곳에 저장된 데이터를 공동 소유하고 유지할수 있습니다.

데이터베이스는 또한 다음과 같은 기능을 제공해야 합니다.

임의적이고 비정형인 질의에 대해서 실시간 처리로 응답해야 합니다.

삽입, 삭제, 갱신을 하면서도 현재 데이터 구조와 데이터베이스 시스템을 안정적으로 유지해야 합니다.

여러 유저가 공용 데이터에 동시 접근 가능해야 합니다.

포인터를 기억할 필요 없이 데이터값만 가지고도 참조 가능해야합니다.

데이터베이스는 다음과 같은 특징 3가지를 가집니다.

복잡한 자료를 추상화하여 보관해야합니다.

프로그램과 자료구조가 독립되어 있어야합니다.

데이터베이스가 알아서 자료의 구성과 내용을 관리하고 기억해야합니다. 이는 metadata로 DMBS 카탈로그에 저장됩니다.

제일 간단한 데이터베이스를 그림으로 나타내 보겠습니다.

개체는 즉 사람입니다. 사람을 속성으로 구분하여 보관하게 되고 속성은 데이터의 가장 작은 논리적 단위이자, 단독 존재하는 것이 불가능한 데이터입니다. 이 속성이 가질 수 있는 값을 모아놓은것이 바로 도메인입니다. 관계는 개체 집합 즉 {김똥깨(), 정방식(), 손철수()}와 같은 개체 집합 내의 관계나 개체 집합 끼리의 관계 등 여러 관계가 존재합니다.

데이터베이스 관리 시스템 (DMBS)

데이터베이스 사용을 위해서는 DMBS가 필요합니다. 이는 응용 프로그램이 데이터베이스를 쉽게 사용하게 도우며, 데이터베이스를 제어하거나, 접근 방법을 제시하거나, 관리하는 기능을 수행합니다. 이는 특히 파일 시스템의 데이터 종속성 문제를 해결하기 위해서 사용되며, DMBS에서는 응용은 파일 시스템을 사용하는것과는 달리 DMBS에 간단히 요청하는 방식으로 데이터에 접근이 가능합니다.

DMBS의 필수적인 기능은 다음과 같습니다.

응용과 데이터베이스가 서로 자료를 인터페이스 하기 위한 방법인 Key를 제공해야 합니다.

데이터베이스를 사용자가 제어할 수 있도록 검색,갱신,삽입,삭제를 지원해야 합니다.

데이터베이스 시스템이 무결성(정확성, 안정성)을 늘 유지할 수 있도록 제어해야 합니다.

무결성, 보안, 권한 검사, 동시 제어, 데이터베이스 복구

이와 같은 기능을 가진 데이터베이스의 장점과 단점은 다음과 같습니다.

DMBS의 구성

DMBS구성은 다음과 같습니다.

DMBS의 구성 요소

DDL이란 Data Definition Language로 데이터 정의어를 의미합니다. 즉 데이터 생성 수정 삭제에 대한 스킴을 정의합니다.

DML은 Data Manipulation Language로 데이터의 Search Insert Delete Update등에 대해 통제하는 언어입니다.

질의어는 DQL으로 Data Query Langauge로 데이터 검색을 지원합니다.

DDL 컴파일러는 DDL로 작성된 스킴을 처리하여 카탈로그 데이터 사전에 저장합니다. 이는 런타임 데이터베이스 처리기를 호출하지 않고 즉시 저장 데이터 관리자를 호출합니다.

질의 처리기는 일반 사용자가 DQL로 질의를 하면 이 구문을 분석(파싱)한 뒤 컴파일하여 런타임 데이터베이스 처리기를 호출합니다.

좋은 질의 처리기는 질의를 정확한 의미로 변환하고, 효율적으로 변환해야합니다.

DML 예비 컴파일러는 컴파일 하기 전에 응용 프로그램의 코드에서 DML들만 별도로 추출합니다. 나머지는 해당 언어의 컴파일러로 보냅니다.

DML 컴파일러는 DML을 컴파일하고 런타임 데이터베이스 처리기를 실행합니다.

런타임 데이터베이스 처리기는 컴파일된 코드들을 실행합니다. 이 명령들은 저장 데이터 관리자를 통해 디스크에 전달됩니다. 런타임 데이터베이스 처리기는 응용프로그램이 실행된 시간 내내 그 실행을 제어합니다.

이는 트랜잭션 관리자와 병행하여 실행되며 데이터 접근중 보안(권한 체크) 데이터의 무결성 검사를 시행합니다.

I/O 장비 정리

핑구힝구 — Wed, 15 Dec 2021 12:28:44 +0900

I/O Devices (tistory.com)

I/O Devices

I/O system은 컴퓨터 시스템에 매우 중요합니다. 입력을 받아야 출력도 하고, 프로그램도 실행할 수 있겠죠? 이 I/O system의 주요 세가지 이슈에 대해서 오늘 알아보도록 하겠습니다. I/O system이 어떻

penguintravler.tistory.com

1) I/O는 Hierarchy 구조를 이룸 (Physics and Cost)

2) System에 Integrate 시키는 방법

Register사용 (Status, Command, Data)

Special I/O instruction 쓰기 아니면 Memory mapped I/O 쓰기

3) I/O OS 관리법

Polling ( Simple 동작잘함, CPU낭비됨 )

Interrupt 사용하기 ( CS 비쌈 )

Poll, Interrupt는 나눠서 사용함.

4) 고급 I/O 관리법

Copy data from memory하는 명령 하는거 시간 오래걸림

Programmed I/O 대신 DMA Controller사용하기

HDD란? (tistory.com)

HDD란?

Hard Disk Drive Hard Disk Drives, Disk Scheduling, RAID Hard Disk Drive 하드 디스크는 실제로 디스크로 이루어져있고 이 디스크를 돌리면서 Arm으로 데이터를 읽는 구조입니다. 구체적인 구조를 한번 볼까요..

penguintravler.tistory.com

5) Disk Access Time = Seek Time + Rotational Latency + Transfer Time

6) Logical Block Mapping

7) FCFS , SSTF, SCAN, CSCAN

RAID 0 : Performance가 좋음.

RAID 1 : Low failure rate, Read 빠름 , Capacity가 안 좋음

RAID 4: n-1개 저장 블록이랑 parity Block하나.

RAID 5: Parity 전용 block 없음 random performance가 더 좋음 Parity Disk 병목이 없음

RAID 6: Parity 두개임

Flash-based SSD (tistory.com)

Flash-based SSD

SSD란 뭘까요? Solid State Storage Drives는 mechanical(moving parts)한 부분이 없습니다. 그래서 HDD보다 응답시간이 빠르고, 작업을 처리하는 양도 더 많죠. 다만 DRAM과는 다르게 파워가 끊겨도 정보가 손실..

penguintravler.tistory.com

9) Floating Gate Transistor, Nand Flash Memory

10) Cell -> Page(Read Write) -> Block(Erasure) -> flash die

11) Read > Write > Erasure

12) Multi Level Cell 2차원 3차원 적층

13) Flash Translation Layer ( Lowest Write amplication needed )

14) Direct mapping (Amplication High)

15) Log Structured FTL (Amplication Low)

- Garbage Collection needed

- Need Mapping Table

- Demand - based FTLs Locality 사용하여 DRAM에 올리기

16) Wear Leveling

Dynamic Wear Leveling, Static Wear Leveling

Memory Virtualization 정리

핑구힝구 — Wed, 15 Dec 2021 12:03:41 +0900

Virtual Memory and Adress Translation (tistory.com)

Virtual Memory and Adress Translation

1. Computer Data Storages 2. Memory Virtualization 3. Adress Translation 1. Computer Data Storages 우리가 예전에 살펴보았던 Memory는 Object Code, Program, Os data, Stack등을 포함한 Virtual한 Memory..

penguintravler.tistory.com

1) 메모리의 종류와 Multi level cell Technique에 대한 간략한 소개

2) Memory Hierarchy가 동작가능한 이유 (Temporal Locality, Spatial Locality) (Data reference, Instruction Reference)

3) Memory Virtualization (Virtual Address Space + Addres Translation)

4) Benefits of Memory Virtualization (Efficiency, Protection, Ease of Programming)

5) Design Goal of Address Translation (Transparency(unware of Address Translation), Protection, Flexibility)

6) Dynamic Relocation (메모리 낭비 어마어마함)

7) Segmentation (Externel Fragmentation, Hard to Free space Manage, Compaction 비쌈)

Free Space Management (tistory.com)

Free Space Management

우리는 그래서 남는 공간을 어떻게 관리해 주어야 할까요? Free space management는 variable sized unit이 포함되어 있어 매우 까다롭습니다. (segmentation 사용할 경우, heap allocation 사용할 경우 발생) 그..

penguintravler.tistory.com

8) Free Space Manage 기술 (Splitting, Coalescing) (header, magic number) (mmap, sbrk) (Best Fit, Next Fit, Worst Fit, First Fit)

Paging (tistory.com)

Paging

저번에 Segmentation에 대해서 알아보았죠? 그런데 Segmentation에는 문제점이 많습니다. Externel fragmentation Free space management가 복잡하다는 점 Compaction이 비싸다는 점 또 Code구간 Stack구간 Heap구..

penguintravler.tistory.com

9) Paging

장점 : Flexible, Simple

사용하는 Bit : (Valid Bit, Protection Bit, Present Bit, Dirty Bit, Reference Bit)

Paging 단점 (Huge Page Table, Performance Degrade, Internel Fragmentation)

Huge Page Table -> Hybrid, multi level paging

Performance Degrade -> TLB Cache

Translation Lookaside Buffer (tistory.com)

Translation Lookaside Buffer

TLB에 대한 내용은 저번에 Paging에 대한 글에서 살펴보았었죠? TLB는 full associative method를 통해 관리됩니다. 보통 TLB는 32,64,128개 정도의 Entry가 있는데, Hardware가 TLB에서 이 엔트리를 parallel하게..

penguintravler.tistory.com

10) TLB

full associative method

Who manage ( Software, Hardware )

Flush vs ASID

Paging with Smaller Tables (tistory.com)

Paging with Smaller Tables

Page Table 은 굉장히 크기가 큽니다. 동작중인 프로세스를 전부 저장해야 하기때문에 그 부담이 더 크죠. 그렇다고 이렇게 Page Size를 늘이면 Page Table의 크기는 줄어들지만 Internel Fragmentation이 매우.

penguintravler.tistory.com

11) Hybrid Approach

Segement의 단점을 공유함.

12) Multi Level Paging

장점: level of Indirection(Page다 따로따로 저장가능), DRAM에 올리기 쉬워짐

단점: Miss 나면 참조해야할게 아주 많음, 복잡함

13)Inverted Page Table

장점: Page Table이 하나만 있으면 됩니다.

단점: Hash Collision이 일어납니다

해결법은 PFN을 PTE에 추가해주면 됩니다. 그러면 PTE로 PA를 바로 알수는 없는데, Sharing문제도 해결할 수 있습니다.

Swapping and Page Replacement Policy (tistory.com)

Swapping and Page Replacement Policy

Operating System은 Virtual Space를 매우 크게 할당해 줍니다. 그것이 편리하고, 사용하기 쉽기 때문이죠. 그러니 저희는 Virtual Memory가 가득 차있을지, 아닐지 신경을 쓸 필요가 없는 것입니다. 그렇다면

penguintravler.tistory.com

14) Swapping Swap in, Swap out

15) Effective Accesstime Page fault가 어마어마한 영향 줌

16) Page는 언제 비우나? (Swap Daemon)

17) FIFO(Belady's anomaly 벨리데이의 모순), RANDOM, LRU(Clockwork Algorithm), LFU

18) Dirty Page (modified bit) - pending write

19) Demand or Prefetching

20) Thrashing

FSCK and Journaling

핑구힝구 — Wed, 15 Dec 2021 06:14:13 +0900

FSCK와 Journaling은 모두 Crash Consistency문제를 해결하기 위한 방법입니다.

Crash Consistency 문제란 뭘까요?

많은 Data Structure과는 다르게, File system의 Data Structure은 무조건 안정되어야합니다.
File System을 crash-consistency problem을 피하면서 안정시키는 것입니다.
즉 그러니 쓰다가 전원이 나가거나 해도 File System이 보존되어야 하는것이죠.

Crash Consistency Problem이 어떻게 발생할지 어떤 경우에 발생할지 한번 볼까요?

저희가 파일을 쓰게 되면 Data Bitmap, Inode, Data Block에 정보를 써 주어야 합니다.

하지만 이것은 동시에 일어나는 동작이 아니라 Page Cache나 Buffer Cache에 저장되어 있다가 동작합니다.

그러니 file system이 inconsistent한 state에 자주 놓인다는 의미이죠.

그럼 여기서 Crash Scenario를 한번 보도록 할까요?

한개를 쓰다가 Crash가 날 경우
- Case 1a: Db만 썼을 경우
  - inode도 없고 아무것도 없는 dummy data가 됩니다.
  - 한번도 쓰지 않았던 것과 같은 상태이기에, consistency의 문제가 없습니다.
- Case 1b: inode만 썼을 경우
  - inode에 주소는 업데이트 했는데 거기에 있는 데이터는 garbage data가 됩니다. 고로 File system Incosistency가 일어납니다.
- Case 1c: bitmap만 썼을 경우
  - Space leak이 일어납니다. 즉, point해 줄 inode가 없어 free도 되지 않고 access도 되지 않지만 그 누구도 data를 그곳에 쓸 수 없습니다. 고로 이 경우도 file system inconsistency 입니다.
두개를 쓰다가 Crash가 날 경우
- Case 2a: inode와 bitmap만 썼을 경우
  - 문제가 없습니다.
- Case 2b: inode와 datablock만 썼을경우
  - bitmap이 없기 때문에 언제던지 그 위치에 다른 file이 덮어써질 수 있습니다. 즉 Inconsistency가 발생합니다.
- Case 2c: bitmap과 datablock만 썼을 경우
  - bitmap만 쓴 경우와 같습니다. = case 1c.

왜 이런 문제가 일어날까요? file system을 atomically하게 작성하지 않기 때문입니다. 하지만 우리는 atomically하게 작성을 할 수 없죠. Disk가 한번에 한 번만 write하는 것을 허용하기 때문입니다.

그래서 이것을 해결하기 위해 fsck를 사용합니다. fsck는 언제 실행되냐면, file system이 Mount 될때 실행됩니다.

fsck는 file system checker로 모든 free block, inode , bitmap을 check합니다.

Inode state
- 각 inode는 corruption 되어 있거나 다른 문제가 있는지 Check됩니다.
  - 예를들어 type Check 등이 있습니다.
- 만약 문제가 있으면 고치기 어렵기 때문에 그냥 suspect로 지정하여 clear시켜 줍니다.
Free blocks
- fsck가 inode를 scan하여 map된 block을 전부 조회하고 만약 bitmap과 inode와 consistency가 없을경우 고쳐줍니다. inode를 믿는 방향으로 고치기 때문에 Case 1c와 2b만 고칠 수 있습니다.
Directory checks
- Directory는 특정한 file system에 의해 특정한 foramt으로 만들어집니다.
  - fsck는 user file에 어떤 content를 집어 넣을지는 모릅니다.
- 고로 file system content와 directory간의 integerity check만 합니다.
  - 예를 들어, Directory안에 .과 ..이 올바르게 들어가 있는지. 각 directory entry안에 있는 inode가 allocate되어 있는지.

다만, file system checker는 모든 문제를 고치는 만능 도구는 아닙니다. 예를 들어 case 2a의 경우 metadata는 일치하기 때문에 internally consistent 합니다.

fsck를 빌드하려면 파일 시스템에 대한 많은 지식이 필요합니다.

그리고 또, fsck는 크고 중요한 문제가 있습니다, 일단 너무 느리고 전체 디스크를 Scan하는것은 많은 minute과 hour를 필요로 합니다. 이 말은 fsck의 performance는 어마어마하게 비싸 Overhead를 심각하게 일으킨다는 뜻입니다.

그래서 fsck 대신 Journaling (WAL: Write Ahead Logging)이라는 방법을 대신 사용합니다.

Structure를 쓰기전에 내가 무엇을 쓰는건지 알려주는 little note를 먼저 씁니다.
이 Note를 write하는 것은 "write ahead" part라고 부르고, structure를 쓰는건 "log"라고 부릅니다.
만약 crash가 발생하면 note로 돌아가서 확인할 수 있습니다.
즉 무엇을 고칠지를 전체 데이터를 스캔하는것보다 훨씬 효율적으로 알 수 있다는 의미입니다.

Journaling 은 Ext2에서는 지원되지 않고 Ext3에서는 Journaling을 지원합니다.

구체적으로는 다음과 같습니다.

Journal Write
- Journal즉 Log를 먼저 남깁니다. 이 Log에는 pending될 Data와 Txb, TIB가 포함됩니다.
Journal Commit
- Journal 을 write했으면 transaction commit block을 써서 제대로 써져있는지 확인시켜줍니다. (TxE)
Checkpoint
- 이 Transaction을 쓰는 Journal write이 끝나면 이제 Structure를 업데이트 해 줍니다.
Free
- Transaction을 free해 줍니다. (Journal Superblock을 사용)

Fast File System

핑구힝구 — Tue, 14 Dec 2021 22:30:19 +0900

그전에 File System Implementation에서 살펴보았던

와 같은 구조는 간단하지만 매우 안 좋은 성능을 가지고 있습니다.

Problem 1: Positining cost가 높습니다.
- Data가 Disk에 저장되어 있다면 AccessTime이 데이터가 조각나있을 수록 높을텐데 이를 고려하지 않은 시스템입니다.
- Expensive한 Positioning Cost를 가집니다.
  - 예를들어 Data Block과 파일은 서로 자주 접근해야하는 관계임에도 불구하고 매우 멀리 떨어져있습니다.
  - 이럴 경우 Seek Time이 늘어납니다.
Problem 2: Fragmentation이 이것을 더 심각하게 만듭니다.
- 만약 데이터 A-B-C-D가 순서대로 저장되어 있었더라도 B와 D가 지워진 후 E를 저장하려면 E가 조각나있는 상태가 됩니다.

그래서 FFS(Fast File System)을 사용하게 됩니다.

FFS는 "Disk aware"한 방식으로 기존의 Access method는 내버려둔 상태로 Data Structure(=internel implementation)만 바꾸는 방식으로 구현됩니다.

FFS는 disk를 Cylinder Group(=Block Group)으로 나눕니다. Cylinder는 물리적인 Disk의 Surface에 담겨 있는 Track들을 의미합니다.

이 방식은 Seek performance를 개선하기 위해 고안된 것으로, 같은 파일을 같은 그룹에 넣습니다.

즉, 기본적인 Policy는 관련있는 데이터를 같이 둔다 입니다.

Policy 1: Directory는 어디에 두어야 할까요?
- Cylinder Group중 할당된 디렉토리 수가 적고, inode number가 많이 남는 곳을 선택합니다.
- Directory data와 innode를 같은 그룹에 저장합니다.
Policy 2: File은 어디에 두어야 할까요?
- 모든 파일을 그것이 속한 디렉토리에와 같은 group에 배치합니다.

그러면 가까운 것은 더 가깝게 배치되죠?

그러나 Issue 들이 있습니다.

Group이 너무 빨리 찹니다.
이게 인접할 거라는 보장이 존재하지 않습니다.
- SEER Trace : 얼마나 인접해 있는지를 체크하는 Trace입니다.
Large File의 경우 어떻게 배치해야할까요?
- Large file은 Cyclic Group의 block 전체를 채웁니다.
- 그것은 related된 파일을 같이 배치할 수 없습니다.
- 그래서 Large File은 chunk로 나누어 disk전체에 나뉘어저 배치됩니다.
  - Chunk사이즈는 충분히 크게 해주고, 이에 따르는 Overhead는 데이터를 전송하는데 사용하여 상각(armortization) 시켜줍니다. 즉 전송 시간, Seek Time의 비율을 조정해 주는 것입니다.
- Inode는 한개의 Cyclic Group에만 저장하고 Data는 분산시켜 줍니다.

Swapping and Page Replacement Policy

핑구힝구 — Tue, 14 Dec 2021 22:00:02 +0900

Operating System은 Virtual Space를 매우 크게 할당해 줍니다. 그것이 편리하고, 사용하기 쉽기 때문이죠.

그러니 저희는 Virtual Memory가 가득 차있을지, 아닐지 신경을 쓸 필요가 없는 것입니다.

그렇다면 만약 Virtual Memory를 다 쓰는 프로그램이 아주 많아서 메모리가 부족하면 어떻게할까요?

이를 위해서 OS는 Swapping 을 사용합니다.

Disk안에 Page Size의 Unit을 만들어 두고 계속해서 Swap in, Swap out 시키는 것이죠.

이럴 경우 Page Table에는 present bit가 추가됩니다. 그러니까 Memory에서 이것을 찾아야하는건지 Disk에서 찾아야 하는건지 알려주는 용도이죠.

Page Hit, Page fault는 이것이 Physical Memory에 각각 있을 경우, 없을 경우를 의미합니다.

그렇다면 Page fault는 어떻게 해결할까요?

Page miss가 Page fault라는 Exception을 발생시킵니다.
OS의 fault handler가 Victim을 Select 합니다.
Victim을 Disk에 써 주고, Physical Memory에 Fault를 발생시킨 데이터를 써 줍니다.
다시 한번 요청을 하면 Page Hit이 나게 됩니다.

그럼 어떻게 Victim을 Select할까요? 만약 자주 쓰는 걸 Victim Select를 했다가는 Page fault의 비용이 매우 비싸기 때문에 성능에 Critical 한 영향을 미칠 것입니다. (Disk는 DRAM보다 10,000x배 느림)

Effective Access Time을 통해서 Page fault가 영향을 얼마나 줄지 한번 봐 보도록 할까요?

진짜 엄청난 영향을 주죠?

그럼 어떻게 Page fault를 줄일 수 있을까요?

일단 전에도 언급했듯이 정보에는 Locality가 있기 때문에 page fault는 생각보다 덜 발생하게 됩니다. 이 Locality를 얼마나 잘 살리느냐가 바로 Replacement Policy의 핵심입니다.

참고로 언제 Replacement가 일어날까요?

Page가 가득 찼을때 할까요? 실제로는 아주 약간의 memory를 늘 free 상태로 유지하고 있습니다.

이를 Swap Daemon이라고 하는데요, free space에 High Watermark와 Low Watermark를 지정하여서, 빈 공간이 줄어 LW에 도달하게 되면 Swap Daemon이 Page를 쫓아내서 HW까지 빈 공간이 늘어나도록 만든 후 멈춥니다.

이제 Replacement Policy를 봅시다 OS는 Memory에게 누구를 갈아 끼울지를 결정하는데, 이를 결정하는 Policy가 바로 Replacement policy 입니다.

가장 간단한 Policy는 FIFO입니다. 가장 먼저 들어온 것을 내보내는 것이죠.

이것은 얼마나 자주 사용되는지를 고려하지 않는 방식이라 비효율적입니다.

또한, Cache가 늘어날수록 Hit rate는 올라가야하는데 FIFO는 증가하기도 합니다. 이것은 Belady's anomaly라고 불리는 현상입니다.

또 하나의 방법은 Random 입니다. Random은 종종 Optimal hit rate에 가까워질정도로 좋아지기도 합니다.

여기까지가 History 없이 Victim을 Select하는 방법이었고 LRU(Recency), LFU(Frequency)는 history를 고려하는 방법입니다.

그렇다면 이것들이 각각의 Worklord에서 어떻게 동작할지를 한번 살펴볼까요?

Locality가 없기 때문에 Optimal 한 경우를 제외하면 그 어떠한것도 의미가 없습니다.

Locality가 존재할 경우 LRU가 제일 자주 쓰이는 Page들을 보관하기 때문에 제일 성능이 좋습니다.

만약 1~50 이라는 데이터를 Loop로 반복해서 넣는 경우 LRU나 FIFO는 Locality를 보장할 수 없습니다.

이제 LRU를 구현하는 방법에 대해서 알아볼까요?

Counter 사용하기
- 페이지에 Reference할 때마다 시간을 Counter에 저장해 줍니다.
- 제일 작은 Counter를 찾아 페이지를 제거합니다.
  - 단점은 Search through를 해 주어야 한다는 것입니다.
Stack 사용하기
- Page가 Reference되면 Stack의 제일 상단으로 옮겨줍니다.
  - 장점은 Search through를 해줄 필요가 없다는 것입니다.
  - 단점은 Update를 해주는 것이 비싸다는 것입니다.
Clock Algorithm사용하기
- Hardware의 Support가 필요합니다.
  - Page가 Reference되면, Reference bit가 1로 바뀝니다. (HW)
  - 하드웨어는 절대 이 bit를 0으로 바꾸지 않고 OS가 바꾸도록 해 줍니다.
  - 모든 페이지는 circular list로 system에 의해 arrange됩니다.
  - clock의 시침이 시작할 페이지를 가리키고 있습니다.
  - Page replacement가 요구될때 돌면서 victim을 select할지 말지 결정합니다.
    - bit가 0이면 victim이 됩니다.
    - bit가 1이면 0으로 만들고 다음 page로 돕니다.
  - 이 경우 LRU만큼 성능이 뛰어나지는 않습니다.

LRU가 아니라 다른 알고리즘을 Implement할 때 고려되는 것들도 있습니다.

Dirty Page
- HW가 modified bit(= dirty bit)를 포함해 줍니다.
- 이것은 Page가 수정되었다는 의미로, evict하려면 Disk에 다시 Write해 주어야 합니다.
- 고로, 비용이 싼 Clean Page가 Victim이 됩니다.
- Dirty Page를 Disk에 기록하는 순간은 Dirty Page를 많이 모아 pending wirte가 될때 한번에 써 주는 것입니다. 그러면 IO를 최소화 할 수 있습니다.
Page를 Memory에 언제 불러올까요?
- Demand : 요구 될 때 불러옵니다.
- Prefetching : 미리 예상하여 불러옵니다.
Thrashing
- 메모리가 과하게 Subscribed 되었을때 즉, Running Process가 요구하는 memory의 양이 physical 메모리를 초과하였을때 발생합니다.
- Subset of Process를 돌리지 않도록 결정합니다. 즉 돌아가는 Set of Process를 줄여줍니다.

Paging with Smaller Tables

핑구힝구 — Tue, 14 Dec 2021 11:24:44 +0900

Page Table 은 굉장히 크기가 큽니다. 동작중인 프로세스를 전부 저장해야 하기때문에 그 부담이 더 크죠.

그렇다고 이렇게 Page Size를 늘이면 Page Table의 크기는 줄어들지만 Internel Fragmentation이 매우 심각해집니다.

그렇다면 이것을 어떻게 해결할 수 있을까요?

일단 Hybrid Approach를 해 봅시다.

일단 Page Table의 대부분은 비어 있습니다. 모든 프로그램이 Address Space를 전부 채워서 사용하는것은 아니죠.

이 성질을 활용하여 segmentation과 paging을 합칠 겁니다.

전체 Address가 PageTable을 가지는게 아니라, cod heap stack 즉 logical Segment 하나당 PageTable을 가지는 것입니다.

그러면 각 세그먼트에는 두 가지 register가 필요하겠죠?

Base는 segment를 physical memory로 포인트 합니다.
Bound는 Limit은 Page Table이 끝나는 지점을 Point 합니다.

이럴 경우 Virtual Address는

VA of Hybrid Approach

다음과 같이 됩니다.

Segment Table로 Seg를 사용해 들어가서 Bound와 Base를 찾고 Base에 Page Table 주소가 있으니, 여기서 VPN을 사용하여 Paging처럼 Memory에 Access하는 것입니다.

다만 이럴 경우 Externel Fragmentation과 Free space management라는 Segmentation의 문제가 똑같이 일어나게 됩니다.

그럼 어떤 방법을 사용해야 할까요?

Multi-level Page Tables라는 기술이 있습니다. Page Table을 Tree같은 것으로 조각내는 것이죠.

이렇게 될 경우 장단점이 존재하는데,

Advantage
- Memory를 아낄 수 있습니다.
  - Page Table을 여러개로 나누어 Allocate될 부분을 줄일 수 있습니다.
- Memory를 Manage하기 쉽습니다.
  - 페이지 테이블을 저장할때 페이지 테이블이 연속적으로 저장되었어야하는데 이제 페이지테이블을 나누어 저장할 수 있습니다.
  - 이를 level of Indirection이라고 합니다.
Disadvantage
- Time-Space trade off : TLB miss가 나면 두번 이상 memory에 접근해야 합니다.
- Complexity : 구현이 어렵습니다.

그런데 요즘 메모리가 커지고 있어서, 사실 많은 Page Table을 쓰지 않는 방식도 고려되고 있습니다.

그러니까 Physical Memory 의 사이즈 전체를 Inverted Page Table로 만들고, 그곳에서 찾은 PTE가 그냥 Physical Memory로 흘러가는 것이죠.

Advantage
- Inverted Page Table은 Memory를 효율적으로 사용합니다. Process별 PageTable을 전부 저장할 이유가 없습니다.
- TLB miss가 일어났을때 Memory Reference가 적습니다.
Disadvantage
- Hash collision 문제가 일어납니다.
  - 이로 인해서 Worst -Access Time이 될 수도 있습니다.
  - Entry의 숫자를 늘립니다. 즉 메모리 스페이스를 늘려야 합니다.
- Page를 Share할 수 없습니다.
- Swapping이 지원되지 않습니다.

여기서 Hash collision은 PFN을 Inverted PageTable에 더해줌으로써 해결할 수 있습니다.

그러면 PTE로 Physical Memory를 바로 알 수는 없지만, Sharing Problem역시 해결할 수 있습니다.

Breadth-First Search

핑구힝구 — Mon, 13 Dec 2021 09:39:01 +0900

BFS Search Algorithm

def BFS(start):
    Set L_i = [] for i = 1,..,n
    L_0 = {start}
    for i = 0,...,n-1:
        for u in L_i:
            for each v in u.neighbor:
                if v.state = unvisited:
                    mark v as visited, and put in L_i+1

Running Time은 O(n+m)으로 DFS와 같습니다.

Application - Shortest Path

만약 Weight이 걸려 있지 않는 그래프의 경우 시작점으로부터의 최단 거리를 알 수 있습니다.

Application - Bipratite Graph

Biparatite Graph란 연결된 노드가 모드 Bipartite한 경우입니다.

이 Graph가 만약 Not Bipartite하다면 cycle of odd length를 찾을 수 있습니다.

그래서 BFS로 어떻게 Bipartite를 검증할까요?

아까 Visited Node에는 Coloring을 하지 말라고 했는데 Visited Node지만 Neighbor인 Node에 대해서는 색이 같은지 다른지를 알아봄으로써 이를 검증할 수 있습니다.

Translation Lookaside Buffer

핑구힝구 — Sun, 12 Dec 2021 22:11:59 +0900

TLB에 대한 내용은 저번에 Paging에 대한 글에서 살펴보았었죠?

TLB는 full associative method를 통해 관리됩니다.

보통 TLB는 32,64,128개 정도의 Entry가 있는데, Hardware가 TLB에서 이 엔트리를 parallel하게 검색하여 줍니다.

TLB는 그리고 PFN 이외에도 valid bit, protection bit, ASID(address-space identifier) 등을 또 저장합니다.

이 ASID의 쓰임새는 나중에 알아보도록 하겠습니다.

TLB에는 두가지 이슈가 있는데

1) TLB Miss를 누가 Handle할 것인지 (Hardware vs Software) 이고,

2) Context Switch를 어떻게 관리할 것인지 (Flush vs ASID) 입니다.

1번 문제에 대해서 먼저 살펴보겠습니다.

만약 Hardware가 manage할 경우에 대해 살펴보겠습니다.

Hardware가 TLB Miss를 처음부터 끝까지 알아서 Control 합니다.
- Hardware는 두가지 정보를 압니다.
  1. Memory에 저장된 PTE의 Address (page table base register) (PTBR)
  2. Page Table과 PTE의 format
- Hardware은 Page Table을 "walk" 합니다.
  1. 현재 Page Table로 Jump 합니다
  2. 알맞은 PTE를 찾습니다.
  3. TLB에 들어가기 알맞게 주소를 추출합니다. (Page table translation)
  4. TLB를 업데이트 합니다.
  5. 다시 정보를 Access하여 TLB HIT이 나도록 합니다.

만약 그렇다면 Software가 Manage하면 어떨까요?

실제로도 RISC나 MIPS 구조와 같은 Modern Architecture에서는 TLB Miss를 Operating System에서 관리합니다.

Hardware가 exception을 띄워 TLB miss가 났다는 것을 알립니다.
- 현재의 instruction stream을 멈춥니다.
- Kernel에게 우선순위를 전부 줍니다.
- Trap handler 로 넘어갑니다.
OS내의 Trap handler가 호출된 상황입니다.
OS는 page table의 translation을 살펴봅니다.
OS가 TLB를 업데이트 하기 위해서 특별한 연산을 수행합니다.
OS가 Trap에서 넘어옵니다.
다시 정보를 Access하여 TLB Hit가 나도록 합니다.

각각의 장-단점은 다음과 같습니다.

Hardware-managed TLB
- (+) Efficient 합니다
- (–) CPU Design이 복잡해집니다.
- (–) Page Table의 유연성이 떨어집니다.
- (–) TLB Miss가 날 가능성이 높습니다. (Hardware가 victim을 Choose하기 때문에)
Software-managed TLB
- (+) CPU Design이 간단해집니다.
- (+) Page Table이 유연해 집니다.
- (+) TLB Miss가 날 가능성이 낮습니다.
- (–) 상대적으로 느립니다. ( Not Efficient )

이제 두번째 이슈에 대해서 살펴보겠습니다.

만약 Process A와 B에서 같은 VPN을 가질 경우 어떤 것을 찾아야 할지 알 수 없습니다.

그래서 한가지 방법은 Context Switch가 일어날때 Flush 해주는 것입니다.

Context Swtich가 일어날때 다음 프로세스를 위해서 전부 Flush 합니다.
- 간단한 방법은 전부다 0으로 채우는 방법입니다.
Flush Operation은 언제 발생할까요?
- Software관점에서 보면 하드웨어가 TLB-flush하는 명령을 제공하면 OS가 이것을 호출합니다.
- Hardware 입장에서 보면 (PTBR)이 변경될때 CPU가 clean up 해 줍니다.
Switch마다 발생하는 TLB Miss로 인해서 Overhead가 심해집니다.

그래서 다른 방법인 Identifier (ASID)를 추가하여 이를 확인하는 것입니다. 이 방법이 더 나은 방법입니다.