System Software Laboratory

page eviction할 때 PTE, dirty bit

답변 감사합니다 — Sun, 19 Apr 2026 12:58:49 +0000

swap시 type bit관련 질문이 있습니다

asdf — Sat, 18 Apr 2026 19:17:38 +0000

process 생성시 PTE

시험공부재밌다 — Thu, 16 Apr 2026 18:54:48 +0000

page fault에서 page valid에 대한 질문

시험공부 재밌다 — Thu, 16 Apr 2026 18:37:13 +0000

RaspberryPI Setup 환경 실습 관련 질문

Thu, 16 Apr 2026 17:49:01 +0000

안녕하세요, Lab6: RaspberryPI Setup 환경 실습 관련하여 질문드립니다. 현재 라즈베리파이와 Mac을 랜 케이블로 직접 연결하여 동일한 IP 대역(10.10.10.x)으로 설정한 상태입니다. 이 상태에서는 Mac에서 라즈베리파이로 SSH 및 scp 전송이 정상적으로 동작합니다. 하지만 가상머신(Ubuntu)은 Mac 내부의 NAT 네트워크(192.168.65.x)에 연결되어 있어, 가상머신에서 라즈베리파이(10.10.10.12)로 직접 ping이나 scp가 되지 않는 상황입니다. PPT에서는 다음과 같이 가상머신에서 직접 라즈베리파이로 파일을 전송하는 흐름을 제시하고 있습니다. * scp hello.ko pi@<라즈베리파이 IP>:~/ 이에 따라 아래 두 가지 방법 중 어떤 방식으로 진행해도 되는지 문의드립니다. 1. 가상머신 → Mac → 라즈베리파이 순으로 scp를 이용해 파일을 전달하는 방식 2. 가상머신이 라즈베리파이와 동일한 LAN(10.10.10.x)에 직접 연결되도록 네트워크를 구성한 뒤, PPT와 동일하게 가상머신에서 직접 scp를 수행하는 방식 실습 및 과제 제출 시 반드시 2번과 같이 가상머신에서 라즈베리파이로 직접 전송하는 구조를 맞춰야 하는지, 아니면 1번과 같이 Mac을 경유하는 방식으로 진행해도 무방한지 확인 부탁드립니다. 감사합니다.

ku_binder.h 질문드립니다.

ㅇㅇ — Thu, 16 Apr 2026 16:58:06 +0000

KU_Binder 구현 관련 질문입니다

킹왕짱티라노 — Thu, 16 Apr 2026 03:18:10 +0000

Limited Direct Execution Protocol에 대한 질문

김길동 — Wed, 15 Apr 2026 14:52:32 +0000

5/1(금) 노동절 수업 관련

진현욱 — Wed, 15 Apr 2026 13:19:54 +0000

Linear Page Table과 Multi-Level Page Tables의 비교 슬라이드 질문

OS Oh Yes — Wed, 15 Apr 2026 11:28:36 +0000

segmentation과 paging에서의 메모리 접근으로 인한 overhead 관련 질문

anonymous — Tue, 14 Apr 2026 19:18:20 +0000

------------------------------------------수업게시판 규칙------------------------------------------------ 커뮤니티가 아닌 공적인 수업 게시판으로 서로 간의 예의를 지켜야 합니다. 비밀 게시물의 경우 확인하지 않고 답변해드리지도 않습니다. ---------------------------------------------------------------------------------------------------------- 강의 내용 복습 중 궁금한 점이 있어 질문드립니다. Paging을 배울 때, page table이 메모리에 저장되어 있기 때문에 address translation 과정에서 page table을 한 번 참조하고 실제 데이터에 접근해야 하므로 메모리 접근이 추가되어 성능 저하가 발생한다고 이해했습니다. 그런데 segmentation에서도 제가 아는 바에 의하면 segment table이 메모리에 저장되어 있는 것으로 알고 있는데, 똑같이 주소 변환 과정에서 segment table을 참조한 후 실제 메모리에 접근해야 하므로 결과적으로 paging과 동일한 횟수의 메모리 접근이 발생하는 것이 아닌지 궁금합니다. 제가 생각하기로는 두 방식 모두 table 참조가 필요하다는 점에서 추가 메모리 접근이 발생하는 구조는 동일한 것처럼 보이는데, 강의에서는 paging의 경우에만 이러한 overhead가 강조된 것 같아 혼란이 있습니다. 혹시 이 차이가 segment table의 크기가 page table에 비해 상대적으로 작아서 레지스터 등에 캐시 형태로 저장 될 수 있기 때문인지, 아니면 실제 구현 방식에서 차이가 있기 때문인지 명확하게 이해하고 싶습니다. 제가 이해한 부분 중 잘못된 점이 있다면 함께 설명해주시면 감사하겠습니다.

service name

ㅇㅇㅇ — Tue, 14 Apr 2026 17:43:26 +0000

EEVDF 스케줄러에서 새로운 프로세스의 vruntime 값

산체스 — Mon, 13 Apr 2026 23:46:26 +0000

page, segmetaion 구조 차이 질문

성이름 — Mon, 13 Apr 2026 19:53:15 +0000

Waitqueue 동기화 관련 질문 추가 답변

sslab — Fri, 10 Apr 2026 17:48:35 +0000

------------------------------------------수업게시판 규칙------------------------------------------------ 커뮤니티가 아닌 공적인 수업 게시판으로 서로 간의 예의를 지켜야 합니다. 비밀 게시물의 경우 확인하지 않고 답변해드리지도 않습니다. ---------------------------------------------------------------------------------------------------------- 안녕하십니까, 수강생 여러분. 수업 조교입니다. wait_event 함수 사용에 답변 드릴게 있어 공지드립니다. 지난 수요일 Challenges Review 수업 시간 중에 질문 중 하나가, list_empty() 함수를 통해 리스트가 비어있는지를 확인할 때 race condition을 방지하기 위하여 매 condition 확인 시 lock을 걸어야 하는게 아닌가 라는 질문이 있었습니다. 기존 실습에서 알려드린 wait_event_interruptible() 함수는 condition 확인 시 lock을 자동으로 관리해주지 않기 때문에 condition 확인 시 spin_lock을 임의로 acquire 및 release가 어렵습니다. race condition을 방지하기 위해서는 wait_event 내부에서 프로세스가 잠들기 전 직접 lock을 해제하여 lock을 갖고 잠드는 것을 방지하고 wake up에 의해 깨어나서 condition을 확인할 때 lock을 획득하는 과정이 필요합니다. 해당 과정을 kernel 에서는 매번 깨어날때마다 condition 확인 할 때 자동으로 lock을 관리해주는 함수가 구현이 되어있으며, 대표적으로 wait_event_interruptible_lock_irq() 함수가 있습니다. 기본적인 사용방법은 wait_event_interruptible()과 동일하나 lock을 보유한 상태에서 호출해야 합니다. 예시 코드) spin_lock_irq(&lock); // lock을 걸어주어야 함. wait_event_interruptible_lock_irq(wq_head, condition, lock); 해당 함수에서 condition에 의해 탈출하든, 시그널에 의해 탈출하든 함수가 return 이 되면 lock을 보유하고 있는 상태입니다. 따라서 함수의 호출 전에 lock을 얻고, 종료 후에는 critical section에서 작업 후 lock을 해제하는 코드를 반드시 사용해야 합니다. 만일 해당 함수를 사용하시려면 spin_lock / spin_unlock이 아닌 spin_lock_irq / spin_unlock_irq 함수를 사용하시어, spin_lock의 acquire 및 release를 해주셔야하오니, 유의해주시기 바랍니다. - irq에 대한 내용은 추후 강의에서 설명드릴 예정입니다.

segmentation + paging 관련 질문

학생1 — Thu, 09 Apr 2026 16:02:46 +0000

exit내 cdev_del 순서 질문입니다.

123 — Thu, 09 Apr 2026 12:21:50 +0000

[자료1. Kerenl api[1]-cdev_del], [자료2. LDD3 Chapter 3. p. 56 [2]] 안녕하세요, 저번 수업에서 exit 시 자원 해제 순서에 대해 질문드렸었는데, 스스로 내용을 좀 더 정리해 보았습니다. 결국 궁금한건 cdev_del을 어디서 호출하느냐인 것 같아 몇 가지 자료를 찾아보았습니다. 1. 우선 자료 1을 보면, cdev_del은 새로운 open 요청은 차단하지만 이미 장치를 열어둔 프로세스의 fops(R/W 등) 호출은 가능하다고 나옵니다. 즉, "이미 사용 중인 프로세스가 있어도 cdev_del을 호출하는 것 자체는 문제없다"고 이해했습니다. 2. 제가 cdev_del을 리소스 해제보다 먼저 호출해야 한다고 생각한 이유는 만약 리스트 메모리를 먼저 해제한 뒤 cdev_del을 호출하면, 그 사이(unlock ~ cdev_del)에 새로운 open 요청이 들어올 경우 이미 해제된 메모리에 접근하려고 하기 때문입니다. 3. spin_lock 안에 cdev_del을 넣으면 안되는지 찾아보았는데, cdev_del 구현상 메모리 해제하는 부분이 sleep 될 가능성이 존재한다는 것을 확인했습니다[1]. spinlock 안에서 sleep은 금지되므로 lock 밖에서 호출해야 하는것으로 결정했습니다. 4. LLM을 통해서 추가로 찾아봤을 때, 자료2가 중요한 근거라고 합니다. cdev_add가 호출되는 즉시 장치가 'Live' 상태가 된다고 명시되어 있습니다. LLM은 이 말은 반대로 종료 시에는 cdev_del을 가장 먼저 수행해서 장치를 'Unlive' 상태로 만들어야만, 뒤따르는 자원 해제(kfree 등) 과정이 새로운 진입으로부터 안전해질 수 있다는 설계의 대칭성을 보여준다고 답변했습니다. 최대한 내용을 찾아보았는데, LLM을 사용해서 얻은 답변만으로 cdev_del이 먼저 호출되어야 하는게 맞는가라는 의문이 해소되지 않아서 질문드립니다. 최종 생각하는 exit 구조: static void __exit exit(void){ struct msg_list *cur_msg = 0; struct list_head *pos = 0, *q = 0; unsigned int i = 0; cdev_del(cd_dev); unregister_chrdev_region(dev_num, 1); spin_lock(&lock); list_for_each_safe(pos, q, &list_head){ kfree(); } spin_unlock(&lock); } [1] "The Linux Kernel API — The Linux Kernel documentation". no date, https://www.kernel.org/doc/html/v4.14/core-api/kernel-api.html?highlight=cdev_del [2] "This is the Title of the Book, eMatter Edition", O’Reilly & Associates, Inc., January 2005, https://static.lwn.net/images/pdf/LDD3/ch03.pdf

KU_Binder 구현 관련 질문입니다.

123 — Mon, 06 Apr 2026 22:03:40 +0000

안녕하세요. KU_Binder 과제에서 궁금한 내용 두 가지 부분에 대해 질문드립니다. 현재 서비스 서버 1개가 서비스 1개를 전담하고, 클라이언트는 해당 서비스의 request queue에 요청을 등록하는 구조로 구현한 상태입니다. 1. Request Queue 재확인 (Double-Check) 관련 - 클라이언트가 요청을 추가한 뒤 서버를 깨우면, 서버가 lock을 잡고 queue에 접근합니다. - 보통 멀티 서버에서는 lock 획득 후 queue가 비어 있지 않은지 다시 확인하는 것으로 알고 있습니다. - 1:1 대응 구조인 경우에도 lock 내부에서 queue empty 여부를 다시 확인하는 로직이 필수인지, 아니면 과제 범위에서는 생략해도 무관한지 궁금합니다. 2. wait_event_interruptible() 사용 시 서버 종료 처리 관련 - 현재 커널 함수들을 (kbinder_read())를 wait_event_interruptible()로 구현하였고, - 서버가 Ctrl+C로 종료될 때 발생하는 인터럽트 반환값을 확인하여 return 처리함으로써 rmmod/insmod 문제는 해결했습니다. - 이 확인 절차가 없으면, 불필요한 로직을 실행해서 커널이 깨졌었습니다. - 저렇게 처리 후 서버가 종료될 때 서비스 테이블에 등록된 정보를 함께 제거해야 하는지 궁금합니다. - 등록 해제 로직이 없다 보니 Ctrl+C 이후 재실행 시 이름 중복으로 인해 등록 실패가 발생하는데 - 단순히 인터럽트 반환 처리만 해도 되는지, 아니면 종료 시 자원을 정리하는 로직까지 포함하는 것인지 문의드립니다.

[과제1] 관련 질문

성이름 — Mon, 06 Apr 2026 21:17:47 +0000

Exclusive NonExclusive wait

ㅇㅇㅇ — Mon, 06 Apr 2026 19:05:48 +0000

exclusive wait과 non-exclusive wait을 혼용해서 쓰면, non-exclusive wait이 어느 정도 빈번하게 발생하는 상황에서 exclusive wait이 wake up에 의해 깼을 때, 자원을 할당 받지 못하고 다시 wait이 된다면 queue의 tail에 추가되는 것일까요? 이렇게 되면 해당 wait이 starvation 상태가 될 확률이 높을 것 같은데 추가적으로 exclusive wait의 스케줄링 우선순위를 non-exclusive wait보다 더 높게 해주는지 궁금합니다.