20140708

1. cacloud20에서 Xen guest 설치 시도. 자꾸만 오류가 난다. 내 ubuntu machine에서는 잘 돌아가는 이미지가 cacloud20에서는 작동하지 않는다.

cacloud20 guest error message

정섭이 형이 준 ubuntu-lucid guest 이미지는 잘 되었다.

Ubuntu ISO 이미지로 부팅하려 시도해도 잘 되지 않았다. (unable to find a medium containing a live file system)

문제 해결. 우분투를 설치할 때 F6을 눌러 ACPI 선택을 해제해야 한다. ([1] ubuntu unable to find a medium containing a live file system, http://blog.sina.com.cn/s/blog_617f58370100wd0k.html,
[2] Xen XCP Ubuntu – Cannot Mount CDRom Issue, http://techkiwi.wordpress.com/2013/03/14/xen-xcp-ubuntu-cannot-mount-cdrom-issue/)

한편, 위 방법으로 Ubuntu 설치에는 성공했으나 부팅이 잘 되지 않았다.


2. cacloud20에서 Xen guest를 실행해, 인터넷에 접속토록 하고 싶었다. IP를 다섯 개 할당받음.

IP Address 143.248.188.154~158
Subnet Mask 255.255.255.0
GateWay 143.248.188.1
기본 DNS 143.248.1.177
보조 DNS 143.248.2.177


3. 리눅스 커널 스터디 진행. 스터디 중 zombie process에 대한 이해를 넓힘.
지금까지 zombie process라 함은, 부모가 없는 프로세스라고 이해했었다. 하지만 엄밀하게는 다른 개념인 듯 했다. 위키피디아에 설명이 깔끔하게 나와 있었다.

A zombie process or defunct process is a process that has completed execution (via the exit system call) but still has an entry in the process table: it is a process in the “Terminated state”. This occurs for child processes, where the entry is still needed to allow the parent process to read its child’s exit status: once the exit status is read via the wait system call, the zombie’s entry is removed from the process table and it is said to be “reaped”.

Zombie processes should not be confused with orphan processes: an orphan process is a process that is still executing, but whose parent has died. These do not become zombie processes; instead, they are adopted by init (process ID 1), which waits on its children. The result is that a process that is both a zombie and an orphan will be reaped automatically.

좀비 프로세스는 실행이 끝났지만, 프로세스 테이블에 남아있는 프로세스이며, 고아 프로세스는 부모 프로세스가 먼저 죽어버린 프로세스이다. 동일한 내용을 Operating System Concepts 9th Edition에서도 확인할 수 있었다.

References:
[1] Zombie process, Wikipedia, http://en.wikipedia.org/wiki/Zombie_process
[2] Abraham Silberschatz et al, Chapter 3 Processes, Operating System Concepts 9th Edition


4. 리눅스 커널 스터디에서 thread_info 도입 이유에 대해 토론함. 리눅스 커널 2.6 이전에는 task_struct 구조체를 각 프로세스의 커널 스택 끝 부분에 저장했다고 한다. 리눅스 커널 2.6 이후부터 thread_info 구조체를 커널 스택 끝 부분에 저장해두고, 그것의 멤버 변수인 task로 task_struct를 가지고 있다. 이 이유에 대해 대길이 형께서 의문을 가지셔서 찾아보았고, 그 이유를 찾을 수 있었다.

task_struct is huge. it’s around 1,7KB on a 32 bit machine. on the other hand, you can easily see that thread_info is much slimmer.

Kernel stack is either 4 or 8KB, and either way a 1.7KB is pretty much, so storing a slimmer struct, that points to task_struct, immediately saves a lot of stack space and is a scalable solution.

사용 가능한 커널 스택 크기는 제한되어 있는데, 이를 task_struct가 과다하게 차지하고 있으니 slim한 thread_info를 도입해 scalability를 높이겠다는 것이다.

References:
[1] Need for thread_info structure in Linux 2.6 Kernel?, http://stackoverflow.com/questions/6134226/need-for-thread-info-structure-in-linux-2-6-kernel
[2] Robert Love, Linux kernel development, 3rd Edition, Addison-Wesley

thread_info 도입 이유를 알게 된 것도 좋았지만, ‘그 자료구조를 왜 도입했나?’하는 의문을 가지는 것이 중요하다고 느꼈다.

Advertisements
Tagged with: , , , , , , , , , ,
Posted in 1) Memo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

누적 방문자 수
  • 96,405 hits
%d bloggers like this: