'Etc' 카테고리의 다른 글
[기타] 회사에서의 팁 (0) | 2021.10.29 |
---|---|
[평가] 2021 상반기 (0) | 2021.10.14 |
[ENC] ENC LAB 생활 (0) | 2021.02.14 |
[도움도움] 엔지니어가 갖춰야 할 자세 (0) | 2020.07.09 |
[자격증] 임베디드 기사 2019년 필기 (0) | 2020.01.16 |
[기타] 회사에서의 팁 (0) | 2021.10.29 |
---|---|
[평가] 2021 상반기 (0) | 2021.10.14 |
[ENC] ENC LAB 생활 (0) | 2021.02.14 |
[도움도움] 엔지니어가 갖춰야 할 자세 (0) | 2020.07.09 |
[자격증] 임베디드 기사 2019년 필기 (0) | 2020.01.16 |
[평가] 2021 상반기 (0) | 2021.10.14 |
---|---|
[학회] Call for Papers (0) | 2021.02.26 |
[도움도움] 엔지니어가 갖춰야 할 자세 (0) | 2020.07.09 |
[자격증] 임베디드 기사 2019년 필기 (0) | 2020.01.16 |
[레퍼런스체크] ㅇㄷㅇ (0) | 2020.01.07 |
[채용공고] IBM - Linux Kernel Development Engineer (0) | 2021.09.12 |
---|---|
[채용공고] Naver Cloud - 가상화 코어 기술 연구 및 개발 (SW) (0) | 2021.09.11 |
[채용공고] Amazon - Kernel/Hypervisor Engineer (0) | 2021.09.09 |
struct nvme_dev {
struct nvme_queue *queues;
struct blk_mq_tag_set tagset;
struct blk_mq_tag_set admin_tagset;
u32 __iomem *dbs;
struct device *dev;
struct dma_pool *prp_page_pool;
struct dma_pool *prp_small_pool;
unsigned online_queues;
unsigned max_qid;
int q_depth;
u32 db_stride;
void __iomem *bar;
unsigned long bar_mapped_size;
struct work_struct remove_work;
struct mutex shutdown_lock;
bool subsystem;
void __iomem *cmb;
pci_bus_addr_t cmb_bus_addr;
u64 cmb_size;
u32 cmbsz;
u32 cmbloc;
struct nvme_ctrl ctrl;
struct completion ioq_wait;
/* shadow doorbell buffer support: */
u32 *dbbuf_dbs;
dma_addr_t dbbuf_dbs_dma_addr;
u32 *dbbuf_eis;
dma_addr_t dbbuf_eis_dma_addr;
/* host memory buffer support: */
u64 host_mem_size;
u32 nr_host_mem_descs;
dma_addr_t host_mem_descs_dma;
struct nvme_host_mem_buf_desc *host_mem_descs;
void **host_mem_desc_bufs;
};
실행 중인 프로그램.
Stak, heap, data, code를 포함
프로그램 != 프로세스 (실행 파일이 메모리에 적재될 때 프로그램은 프로세스가 됨)
New : 새로운 프로세스 생성 중 (생성 된 것이 아님)
Ready : 프로세서에 할당되기를 기다리는 중
Running : 명령이 실행되고 있는 중
Waiting : event 발생 대기 중
Terminated : 실행 종료
Process는 OS에 의해 PCB로 관리됨
Process state
Program counter : next instruction의 메모리 주소 위치
CPU registers : 아키텍처에 따라 저장되어야 할 register 상이
CPU-scheduling information
Memory-management information : limit register, pagle table, segment table...
Accounting information : real time used, time limits, account numbers, job or process numbers...
I/O status information : list of I/O devices
1. 프로세스가 실행되면 ready queue에 삽입됨
2. CPU를 할당 받은 후 job 수행
Long-term scheduler
Short-term scheduler
mid-term scheduler
I/O-bound process vs. CPU-bound process
PCB 형태로 관리되며, interrupt 처리 후 context 복구가 필요함
Context switch 동안 다른 처리를 할 수 없기 때문에 빈번하게 발생할 경우 overhead 증가
parent/child process - tree 구조로 유지
PID (Process ID)를 통해 구분
Create: 시스템 콜의 fork(). parent process는 자신과 똑같은 자식 프로세스를 생성
child process는 exec()를 통해 내용을 모두 바꿀 수 있음.
fork() 함수는 parent process에겐 child process의 pid, child process에겐 0을 반환
Linux 기준 pid 0 는 ide process라고 함 (참고: m.blog.naver.com/cksdud1113/222076376311)
root@khy-H81M-DS2V:~# ps -aef
UID PID PPID C STIME TTY TIME CMD
root 1 0 2 03:08 ? 00:00:00 /sbin/init splash
root 2 0 0 03:08 ? 00:00:00 [kthreadd]
root 3 2 0 03:08 ? 00:00:00 [kworker/0:0]
root 4 2 0 03:08 ? 00:00:00 [kworker/0:0H]
root 5 2 0 03:08 ? 00:00:00 [kworker/u8:0]
root 6 2 0 03:08 ? 00:00:00 [mm_percpu_wq]
root 7 2 0 03:08 ? 00:00:00 [ksoftirqd/0]
root 8 2 0 03:08 ? 00:00:00 [rcu_sched]
root 9 2 0 03:08 ? 00:00:00 [rcu_bh]
exit()를 통해 child process 종료
process가 cooperation을 하는 이유
1. information sharing
2. computation speedup
3. modularity
Cooperation을 하기 위해 IPC (Inter-Process Commuication)이 필요함
1. Shared memory
2. Message passing
shared memory 영역은 shared memory segment를 생성하는 process 공간에 존재
두개 이상의 프로세스가 동시에 동작할 수 있어 해당 메모리 영역의 접근 및 프로세싱에 대해 추가 처리가 필요 함
메모리 영역 공유 필요 없이 send/receive를 통해 명시적으로 통신을 수행
질문
1. I/O-bound process vs. CPU-bound process 별 차이점은 무엇이고 주로 어떤 application에 의해 발생하는지. 각각에 더 적합한 scheduling은?
2. long, short, mid - term scheduler라는 표현을 사용하는지? 무엇을 기준으로 기간을 구분하는지
3. context swtich 수행시 PCB는 어디에 저장되는 것인가 (메모리로 알고 있는데 메모리의 stack?) 안전한가
[리눅스] 파일 디스크립터 (0) | 2020.12.04 |
---|---|
[커널] Block I/O Layer (0) | 2020.05.27 |
[파일시스템] EXT파일시스템 (0) | 2020.05.26 |
[파일시스템] EXT3 파일시스템 (0) | 2020.05.26 |
[파일시스템] EXT2 파일시스템 (2/2) (0) | 2020.05.26 |
- 유닉스 계열에서 모든 객체들(정규파일, 디렉터리, 소켓, 파이프 등등)은 모두 '파일'로써 관리가 됨.
- 시스템에서 이 파일들을 접근할 때, 파일 디스크립터를 이용
- 프로세스가 실행 중에 파일을 오픈하면 커널은 해당 프로세스의 파일 디스크립터 숫자 중에 사용하지 않는 가장 작은 값, fd값을 할당
이후 프로세스가 열려있는 파일에 시스템 콜을 이용해 접근할 때, fd값을 이용하여 파일을 지칭.
fd값에는 기본적으로 할당되는 파일 디스크립터가 존재
표준 입력 : STDIN_FILENO -> 0
표준 출력 : STDOUT_FILENO -> 1
표준 에러 : STDERR_FILENO -> 2
<unistd.h>에서 파악할 수 있음
- 리눅스에서는 프로세스마다 파일 디스크립터 테이블을 가지고 있음.
파일 디스크립터 테이블은 open등에서 사용한 flags와 파일 테이블 요소의 위치정보를 포함함.
-> 파일 테이블 : 커널에서 모든 열려진 파일들을 관리하는 테이블.
파일 테이블의 항목 엔트리에는 파일의 상태 flags와 현재 파일의 작업 offset과 파일의 vnode 테이블의 위치 정보등을 포함함.
-> vnode 테이블 : inode 정보와 현재 파일의 크기를 포함함.
(셸에서 시작한 프로세스는 1번 프로세스 이자 모든 프로세스의 부모 프로세스인 "init 프로세스" 에서 fork()를 통해 파일 테이블을 복사)
1) 하나의 프로세스에서 같은 파일을 두 번 연 경우
서로 다른 파일 디스크립터 부여 / 서로 다른 파일 오프셋을 유지
(즉, 프로세스에서 파일 입출력은 open 함수로 연 작업을 구분. => 실제 물리적인 파일이 같은지는 구분 하지 않는다. / but, 같은 v-node를 참조)
2) 두 개의 프로세스에서 같은 파일을 연 경우
root@ibof-Z10PE-D16-WS:~# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15080
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15080
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
#include <stdio.h>
#include <stdio.h>
#include <stdio.h> // printf()
#include <string.h> // strlen()
#include <fcntl.h> // O_WRONLY
#include <unistd.h> // write(), close()
#include <sys/types.h>
int main(void)
{
for(int i=0; i< 1026; ++i)
{
int fd = open("./hello.txt",O_RDONLY);
printf("%d\n", fd);
if (fd == -1)
{
printf("error\n");
}
}
}
sudo ls -trn /proc/[PID]/fd
[운영체제] Chapter 3. 프로세스 (0) | 2021.01.10 |
---|---|
[커널] Block I/O Layer (0) | 2020.05.27 |
[파일시스템] EXT파일시스템 (0) | 2020.05.26 |
[파일시스템] EXT3 파일시스템 (0) | 2020.05.26 |
[파일시스템] EXT2 파일시스템 (2/2) (0) | 2020.05.26 |