반응형

blktrace는 사용자 큐까지 요청 큐 조작에 대한 자세한 정보를 제공하는 블록 계층 IO 추적 메커니즘입니다.

  • 커널 패치 커널 이벤트 로깅 인터페이스를 포함하는 Linux 커널에 대한 패치와 이벤트 추적을 생성하기 위해 블록 계층 내의 영역에 패치합니다.
  • blktrace 커널에서 이벤트 추적을 장기 온 디스크 스토리지로 전송하거나 blkparse를 통해 직접 형식화 된 출력을 제공하는 유틸리티입니다.
  • blkparse 파일에 저장된 이벤트를 형식화하거나 라이브 모드에서 실행할 때 blktrace에 의해 수집 된 데이터를 직접 출력하는 유틸리티입니다.

blktrace  개념도

보이는 바와 같이 Block I/O Layer 단에서 발생하는 이벤트를 CPU 단위로 tracing을 하게 되고 blktrace -> blkparse -> btt -> seekwatcher로 이용해서 분석하게 됩니다. 

 

blkparser : blktrace를 통해 발생하는 CPU별 바이너리 코드 Parsing 해주는 도구 입니다.

btt : btt는 blktrace라는 블록 계층 IO 추적 도구의 사후 처리 도구입니다.

seekwatcher : blktrace내용을 그림(png) 형냍로 분석해주는 도구

 

blktrace 사용법

# blktrace -d /dev/sdp -o trace -w 10
=== sdp ===
  CPU  0:                 8780 events,      412 KiB data
  CPU  1:                 3173 events,      149 KiB data
  CPU  2:                 3600 events,      169 KiB data
  CPU  3:                 1445 events,       68 KiB data
  CPU  4:                 4604 events,      216 KiB data
  CPU  5:                 3764 events,      177 KiB data
  CPU  6:                 1152 events,       54 KiB data
  CPU  7:                 1142 events,       54 KiB data
  CPU  8:                  335 events,       16 KiB data
  CPU  9:                  936 events,       44 KiB data
  CPU 10:                 1470 events,       69 KiB data
  CPU 11:                  385 events,       19 KiB data
  Total:                 30786 events (dropped 0),     1444 KiB data

Blkparsing 사용법

#blkparse -i trace.blktrace.* -d sdp.bin

  ...
Total (trace):
 Reads Queued:       4,833,  117,316KiB     Writes Queued:           0,        0KiB
 Read Dispatches:    4,833,  117,316KiB     Write Dispatches:        0,        0KiB
 Reads Requeued:         0         Writes Requeued:         0
 Reads Completed:    4,828,  116,829KiB     Writes Completed:        0,        0KiB
 Read Merges:            0,        0KiB     Write Merges:            0,        0KiB
 IO unplugs:             0             Timer unplugs:           0

Throughput (R/W): 11,692KiB/s / 0KiB/s
Events (trace): 28,993 entries
Skips: 0 forward (0 -   0.0%)

 

 

Btt 사용법

# btt -i sdp.bin | more
==================== All Devices ====================

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

Q2Q               0.000002693   0.002064896   0.224947065        4832
Q2G               0.000000289   0.000010970   0.010791768       57996
G2I               0.000000214   0.000000961   0.000033457       57996
I2D               0.000000160   0.000005564   0.005938405       57108
D2C               0.000135164   0.003013303   0.035674715        4805
Q2C               0.000168496   0.003040692   0.035678620        4828

==================== Device Overhead ====================

       DEV |       Q2G       G2I       Q2M       I2D       D2C
---------- | --------- --------- --------- --------- ---------
 (  8,240) |   4.3338%   0.3797%   0.0000%   2.1643%  98.6272%
---------- | --------- --------- --------- --------- ---------
   Overall |   4.3338%   0.3797%   0.0000%   2.1643%  98.6272%

==================== Device Merge Information ====================

       DEV |       #Q       #D   Ratio |   BLKmin   BLKavg   BLKmax    Total
---------- | -------- -------- ------- | -------- -------- -------- --------
 (  8,240) |    57996    57996     1.0 |       25       48      256  2830284

==================== Device Q2Q Seek Information ====================

       DEV |          NSEEKS            MEAN          MEDIAN | MODE           
---------- | --------------- --------------- --------------- | ---------------
 (  8,240) |            4833        712982.8               0 | 0(2296)
---------- | --------------- --------------- --------------- | ---------------
   Overall |          NSEEKS            MEAN          MEDIAN | MODE           
   Average |            4833        712982.8               0 | 0(2296)

==================== Device D2D Seek Information ====================

       DEV |          NSEEKS            MEAN          MEDIAN | MODE           
---------- | --------------- --------------- --------------- | ---------------
 (  8,240) |           57996         59415.2               0 | 0(55458)
---------- | --------------- --------------- --------------- | ---------------
   Overall |          NSEEKS            MEAN          MEDIAN | MODE           
   Average |           57996         59415.2               0 | 0(55458)

==================== Plug Information ====================

       DEV |    # Plugs # Timer Us  | % Time Q Plugged
---------- | ---------- ----------  | ----------------

       DEV |    IOs/Unp   IOs/Unp(to)
---------- | ----------   ----------
 (  8,240) |        0.0          0.0

==================== Active Requests At Q Information ====================

       DEV |  Avg Reqs @ Q
---------- | -------------
 (  8,240) |           0.0
...

seekwatcher 

#> ./seekwatcher -t [device]_blktrace.* 

seekwatcher 예제

 

※ btt 분석방법

Q2Q — 요청이 블록 계층으로 전송 된 시간
Q2G — 블록 I / O가 큐에서 대기 한 후 요청이 할당 될 때까지 걸리는 시간
G2I — 요청이 할당 된 시간부터 장치의 대기열에 삽입되는 시간까지 소요되는 시간
Q2M — 블록 I / O가 대기열에있는 시간에서 기존 요청과 병합 될 때까지 걸리는 시간
I2D — 요청이 장치의 대기열에 삽입 된 후 장치에 실제로 발행되는 시간까지 걸리는 시간
M2D — 블록 I / O가 종료 요청과 병합 된 시간부터 요청이 장치에 발행 될 때까지 걸리는 시간
D2C — 장치가 요청한 서비스 시간
Q2C — 요청을 위해 블록 레이어에서 보낸 총 시간

 

※ IO sequence

※ Block IO Tuning Point

1. Q2Q는 Q2C보다 훨씬 큽니다. 즉, 응용 프로그램이 연속적으로 I / O를 발행하지 않습니다. hus, 성능 문제가 I / O 하위 시스템과 전혀 관련이 없을 수도 있습니다.
2. D2C가 매우 높으면 요청을 처리하는 데 시간이 오래 걸립니다. 이는 장치가 단순히 오버로드 된 것 (공유 리소스라는 사실 때문일 수 있음)이거나 장치로 전송 된 작업 부하가 최적화되지 않았기 때문일 수 있습니다.
3. Q2G가 매우 높으면 동시에 대기중인 많은 요청이 있음을 의미합니다. 이는 스토리지가 I / O로드를 유지할 수 없음을 나타낼 수 있습니다.
4. iostat 출력 대기 = Q2C = Q2I + I2D + D2C
5. Q2I + I2D == 스케줄러 시간
6. I2D 시간에는 일정 정렬 대기열 내에서 io의 병합을 개선하는 데 사용되는 플러그 앤 플러그 해제 이벤트 (위에 표시되지 않음)로 인해 많은 추가 시간이 포함될 수 있습니다.
7. D2C 시간은 드라이버 시간, 어댑터 시간, 전송 시간 및 스토리지 서비스 시간 (및 뒤로)을 포함
따라서 D2C / Q2C가 1에 가까워지면 스토리지 구성 요소에 소요되는 시간이 높은 것을 의미합니다.
8. D-> C 시간이 높으면 스위치 카운터 또는 스토리지 박스 자체의 유지 보수 인터페이스와 같은 스토리지의 기본 전송 구조를 검사해야합니다.

 

반응형
반응형

반셀프 인테리어 시 가격의 메리트를 극대화 시키기 위해서는 반드시 직접 시공하는 부분을 넣어야 된다고 생각합니다. 

 

사실 셀프 인테리어를 하는 일반인과 전문가의 차이는 기술력, 경험 등 많은 요인이 있지만 가장 중요한 부분은 장비 부분이라고 생각이 됩니다.

 

사실 셀프인테리어를 하면서 느껴지는 부분은 과연 고가의 장비가 필요하나 입니다. 실제로 전동공구 및 수공구의 가격은 상당히 고가인 경우가 많고 일부 동사무소를 통해 대여가 가능하지만 그렇다고 해서 모든 장비를 대여할 수 가 있습니다만 그렇다고 충분하지 않겠죠

 

 

그래서 간단한 공구를 통해 인테리어 시공의 일부분을 할 수 있는 방법을 소개 하고 추후에 제가 직접 시공한 내용은 포스팅하도록 하겠습니다.

 

- 노후 콘센트/스위치 교체 (난이도 : 하)

 시공 시점 : 도배 전 콘센트/스위치 제거 도배 이후 콘센트/스위치 시공

 실제로 콘센트 시공은 매우 쉽게 할 수 있는 부분 입니다. 요새는 디자인 콘센트라고 해서 메탈, 무광 느낌의 콘센트도 많이 있죠. 여기서 주의할 부분은 2가지 입니다. 첫째, 전기를 시공하는 것이기 때문에 반드시 차단기를 내리고 시공을 하셔야 됩니다. 그 다음 2구 이상의 콘센트를 시공할 경우 반드시 직전의 사진을 미리 찍어 주신 다음에 그대로 시공해 주시기 바랍니다. 이렇게 해야되는 이유는 전기에 대한 감전 문제가 있기 때문에 반드시 차단기를 내려야 되고 그리고 2구 이상의 콘센트는 전기에 대한 지식이 있는 경우에는 손쉽게 배선 작업을 할 수 있지만 그렇지 않는 분들은 어렵기 때문에 이 부분에 신경을 써 주시면 될 겉 같습니다. 

 

- 빠데  / 샌딩 시공 (난이도 : 중)

  시공 시점 : 철거 작업 이 후

  빠데는 사실 인테리어 샵에서 자주 Skip 하는 부분 입니다. 왜냐하면 이 작업은 밑에 숨어 있는 작업입니다.  사실 이 부분은 추후 별도로 Post를 하겠지만 중요한 부분이라 한번 짚고 넘어가고자 합니다. 빠데를 시공해야 되는 부분은 크게 2가지 부분입니다. 도배 제거 한 부분과 몰딩/걸레받이 제거 부분입니다. 특히 오래된 아파트인 경우 일수록 빠데에 필요성은 높아 집니다. 실크도배와 몰딩 / 걸레받이를 제거하게 되면 콘크리트 부분이 떨어지거나  부서지는 부분이 발생하게 됩니다. 보통 이런 경우 마감이 깔끔하게 나오기 위해서는 빠데를 해서 비워진 부분을 매꾸고 샌딩을 해서 평탄화 하는 부분이 필요합니다.

 

- 화장실 2차 방수 (난이도 : 하)

  시공 시점 : 화장실 철거 후 다음 

  화장실을 철거 하게 되면 보통 철거 업체에서 1차 방수를 하게 됩니다. 그렇지만 보다 확실한 방수를 위해서는 2차방수를 해야되지만 1방수가 굳혀지는 일수가 3~4일 정도가 들어가고 2차방수 후에도 3~4일 정도 시간이 걸리기 때문에 생각보다 일당비가 많이 들어가게 됩니다. 그렇기 때문에 2차 방수는 직접하는게 훨씬 좋다고 볼 수 있습니다. 2차 방수하는 방법은 간단합니다. 그저 ... 버리는 붓과 통을 갖고 고뫄스 라는 2차 방수액을 성인 가슴 높이까지 발라주시면 됩니다. 그런데 유의할 부분은 배수구로 뚫어놓은 부분에 액이 들어가는 것은 충분한 보양으로 막아야 됩니다.

 

- 폐자제 처리 (난이도 : 하)

  시공 시점 : 바로바로 

  폐자제 처리 하는 방법은 특히 반셀프 인테리어를 하는데 많이 하게 되는 부분이고 시공업자와 잘 협의가 되면 굳이 제가 해야될 경우도 없죠 특히 건축폐기물은 일반 종량제 봉투로 버리면 절!!!대!!! 안되고 각 동사무소에 문의해서 건축물 폐기 마대를 구매해서 처리방법을 준수해서 버리는게 좋을거 같습니다.

 

- LED 전등 시공 (난이도 : 상)

  시공 시점 : 도배 이후

  LED 전등 시공은 생각보다 어려울 수도 쉬울수도 있습니다. 이 부분은 어떤 전등을 시공하느냐가 핵심입니다. 특히 낮은 천고의 높이를 갖고 있는 아파트에 경우에는 면등을 시공하게 되는데 이 LED 면등은 시공하기가 매우 까다롭습니다. 기존의 전등은 브라켓으로 시공을 하기 때문에 중심 및 시공이 매우 편리합니다. 그렇지만 면등은 석고앙카를 이용해 시공하기 때문에 중심선을 잡기 어려워 2인 시공을 권유 해드립니다.

반응형
반응형

ftrace 란

 

ftrace 리눅스 커널에서 제공하는 가장 강력한 트레이서입니다. ftrace는 커널 개발자에게 축복입니다. ftrace는 커널 세부 동작을 알기 쉽게 출력하기 때문입니다.

 

ftrace의 특징은 다음과 같습니다.
1. 인터럽트, 스케줄링, 커널 타이머 커널 동작을 상세히 추적해줍니다.
2. 함수 필터를 지정하면 자신을 호출한 함수와 전체 콜스택까지 출력합니다. 물론 코드를 수정할 필요가 없습니다.
3. 함수를 어느 프로세스가 실행하는지 알 수 있습니다.
4. 함수 실행 시각을 알 수 있습니다.
5. ftrace 로그를 키면 시스템 동작에 부하를 주지 않습니다.

 

Ftrace는 tracefs 파일 시스템을 사용하여 제어 파일을 출력 파일로 표시합니다.

 

Ftrace를 사용하시기 위해서는 2가지 방법이 있습니다.

1. fstab 설정

tracefs /sys/kernel/tracing tracefs default 0 0

2. mount

mount -t tracefs nodev /sys/kernel/trace

 

※4.1 이전에는 모든 ftrace trace 제어 파일이 debugfs 내에있었습니다. 파일 시스템은 일반적으로/sys/kernel/debug/tracing에 있습니다. 이전 버전과의 호환성을 위해 debugfs 파일 시스템을 마운트 할 때
tracefs 파일 시스템은 다음 위치에 자동으로 마운트됩니다.

 

 

 

Ftrace 파일시스템 설명

※ 참고 : 모든 시간 값은 마이크로 초입니다.

 

  current_tracer :

현재 tracer를 설정하거나 표시하는 데 사용됩니다
구성되었습니다.

  available_tracers :

여기에는 다양한 유형의 trace 프로그램이 있습니다.
커널로 컴파일되었습니다. 그만큼
여기에 나열된 trace 프로그램은
그들의 이름을 current_tracer로 에코합니다.

  tracing_on :

트레이스에 쓸지 여부를 설정하거나 표시합니다
링 버퍼가 활성화되었습니다. 이 파일에 에코 0을 비활성화
trace 프로그램 또는 1로 설정하십시오. 참고로이 function은
링 버퍼에 쓰는 경우 trace 오버 헤드가 발생할 수 있습니다.
여전히 발생하고 있습니다.

커널 함수 tracing_off ()는
링 버퍼에 쓰기를 비활성화하는 커널
이 파일을 "0"으로 설정하십시오. 사용자 공간은 다음을 통해 trace을 다시 활성화 할 수 있습니다.
파일에 "1"을 에코합니다.

function 및 이벤트 트리거 "traceoff"도
이 파일을 0으로 설정하고 trace을 중지하십시오. 어느 것도 할 수 있습니다
이 파일을 사용하여 사용자 공간에서 다시 활성화하십시오.

  trace:

이 파일은 인간의 trace 출력을 보유합니다.
읽을 수있는 형식 (아래 설명). trace은 일시적으로 이루어집니다
이 파일을 읽는 동안 비활성화되어 있습니다 (열린 상태).

  trace_pipe :

출력은 "trace"파일과 동일하지만
파일은 실시간 trace으로 스트리밍됩니다.
이 파일을 읽으면 새로운 데이터가 나올 때까지 차단됩니다
검색했습니다. "trace"파일과 달리이 파일은
소비자. 이것은이 파일에서 읽는 것이
더 많은 현재 데이터를 표시하기 위해 순차적 읽기. 일단
이 파일에서 데이터를 읽고 소비하며
순차적 읽기로 다시 읽지 않습니다. 그만큼
"trace"파일은 정적이며 trace 프로그램이 아닌 경우
더 많은 데이터를 추가하면 동일하게 표시됩니다
읽을 때마다 정보. 이 파일은
읽는 동안 trace을 비활성화합니다.

  trace_options :

이 파일을 통해 사용자는 데이터 양을 제어 할 수 있습니다
위의 출력 중 하나에 표시됩니다
파일. trace 프로그램을 수정하는 option도 있습니다.
또는 이벤트가 작동합니다 (스택 trace, 타임 스탬프 등).

  option :

사용 가능한 모든 파일이있는 디렉토리입니다.
trace option (trace_options에도 있음). option도 설정 가능
또는 "1"또는 "0"을 각각
option 이름을 가진 해당 파일.

  tracing_max_latency :

일부 trace 프로그램은 최대 대기 시간을 기록합니다.
예를 들어, 최대 인터럽트 시간이 비활성화됩니다.
최대 시간이이 파일에 저장됩니다. 최대 trace도
저장하고 "trace"으로 표시합니다. 새로운 최대 trace은
대기 시간이이 파일의 값보다 큰 경우 기록
(마이크로 초).

이 파일에 시간을 반영하여 대기 시간이 기록되지 않습니다
이 파일의 시간보다 크지 않으면

  tracing_thresh :

일부 대기 시간 trace 프로그램은
대기 시간이이 파일의 수보다 큽니다.
파일에 0보다 큰 숫자가 포함 된 경우에만 활성화됩니다.
(마이크로 초)

  buffer_size_kb :

각 CPU의 킬로바이트 수를 설정하거나 표시합니다.
버퍼 보유. 기본적으로 trace 버퍼의 크기는 동일합니다
각 CPU마다. 표시된 숫자는
CPU 버퍼이며 모든 버퍼의 총 크기는 아닙니다. 그만큼
trace 버퍼는 페이지 (메모리 블록)에 할당됩니다
커널이 할당에 사용하는 것으로 보통 4KB입니다.
마지막으로 할당 된 페이지에 추가 바이트를위한 공간이있는 경우
요청한 것보다 나머지 페이지가 사용됩니다.
실제 할당을 요청하거나 표시 한 것보다 크게 만듭니다.
(크기는 페이지 크기의 배수가 아닐 수 있습니다
  버퍼 관리 메타 데이터로 인해. )

개별 CPU의 버퍼 크기는 다를 수 있습니다
(아래 "per_cpu/cpu0/buffer_size_kb"참조)
이 파일에는 "X"가 표시됩니다.

  buffer_total_size_kb :

모든 트레이스 버퍼의 총 결합 크기가 표시됩니다.

  free_buffer :

프로세스가 trace을 수행 중이고 링 버퍼가
프로세스가 완료 되더라도 "해제"되었습니다.
신호로 인해이 파일은 해당 목적으로 사용될 수 있습니다. 가까이에
이 파일의 링 버퍼는 최소 크기로 조정됩니다.
trace중인 프로세스가 있으면 프로세스가이 파일을 엽니 다.
이 파일에 대한 파일 디스크립터를 종료하면 닫힙니다.
링 버퍼는 "해제"됩니다.

disable_on_free option이 설정된 경우 trace을 중지 할 수도 있습니다.

  tracing_cpumask :

지정된 CPU에서만 사용자를 trace 할 수있는 마스크입니다.
형식은 CPU를 나타내는 16 진 문자열입니다.

  set_ftrace_filter :

동적 ftrace가 구성되어있는 경우 (
"동적 ftrace"아래 섹션), 코드는 동적으로
호출을 비활성화하도록 수정 (코드 텍스트 다시 쓰기)
함수 프로파일 러 (mcount). 이를 통해 trace을 구성 할 수 있습니다
실제로 성능 오버 헤드가 없습니다. 이거 역시
특정 function을 활성화 또는 비활성화하는 부작용이 있습니다
trace해야합니다. 이 파일에 함수 이름 반향
trace을 해당 function으로 만 제한합니다.

"available_filter_functions"에 나열된 function은
이 파일에 쓸 수 있습니다.

이 인터페이스를 통해 명령을 사용할 수도 있습니다. 참조
자세한 내용은 "필터 명령"섹션을 참조하십시오.

  set_ftrace_notrace :

이것은 효과와 반대되는 효과가 있습니다
set_ftrace_filter. 여기에 추가 된 function은
trace됩니다. 함수가 set_ftrace_filter에 모두 존재하는 경우
그리고 set_ftrace_notrace, 함수는 _not_ trace됩니다.

  set_ftrace_pid :

함수 trace기가 PID가있는 스레드 만 trace하도록하십시오.
이 파일에 나열되어 있습니다.

"function-포크"option이 설정된 경우
PID는이 파일 포크에 나열되며 자녀의 PID는
이 파일에 자동으로 추가되며 자식은
함수 tracer에서도 trace됩니다. 이 option은
종료 된 태스크의 PID가 파일에서 제거되도록합니다.

  set_event_pid :

이벤트가이 파일에 나열된 PID를 가진 작업 만 trace하도록하십시오.
sched_switch 및 sched_wake_up도 이벤트를 trace합니다.
이 파일에 나열되어 있습니다.

이 파일에서 작업 하위의 PID를 PID와 함께 사용하려면
포크에 추가 된 경우 "이벤트 포크"option을 활성화하십시오. 그 option도
작업이 수행 될 때 작업의 PID가이 파일에서 제거되도록합니다.
종료합니다.

  set_graph_function :

이 파일에 나열된 함수는 함수 그래프를 유발합니다
이러한 function과 해당 function 만 trace하는 trace 프로그램
그들이 전화한다. 자세한 내용은 "동적 ftrace"섹션을 참조하십시오.

  set_graph_notrace :

set_graph_function과 유사하지만 함수 그래프를 비활성화합니다.
function이 종료 될 때까지 function이 종료 될 때 trace.
이를 통해 호출되는 trace function을 무시할 수 있습니다.
특정 function에 의해.

  available_filter_functions :

이것은 ftrace가 처리하고 trace 할 수있는 function을 나열합니다.
전달할 수있는 함수 이름입니다
"set_ftrace_filter"또는 "set_ftrace_notrace".
(자세한 내용은 아래의 "동적 ftrace"섹션을 참조하십시오.)

  dyn_ftrace_total_info :

이 파일은 디버깅 용입니다. function의 수
nops로 변환되었으며 trace이 가능합니다.

  enabled_functions :

이 파일은 ftrace 디버깅에 유용하지만 유용 할 수도 있습니다.
함수에 콜백이 첨부되어 있는지 확인하십시오.
trace 인프라는 ftrace function을 사용할뿐만 아니라
유틸리티를 trace하지만 다른 서브 시스템도 가능합니다. 이 파일
콜백이 첨부 된 모든 함수를 표시합니다
첨부 된 콜백 수
콜백은 여러 함수를 호출 할 수도 있습니다.
이 카운트에 나열되지 않습니다.

콜백이 다음과 같은 함수에 의해 trace되도록 등록 된 경우
"regs 저장"속성 (따라서 더 많은 오버 헤드), 'R'
function과 같은 줄에 표시됩니다
레지스터를 반환합니다.

콜백이 다음과 같은 함수에 의해 trace되도록 등록 된 경우
"ip modify"속성 (따라서 regs-> ip를 변경할 수 있음)
함수와 같은 줄에 'I'가 표시됩니다.
재정의 할 수 있습니다.

아키텍처가 지원하는 경우 어떤 콜백도 표시합니다
함수에 의해 직접 호출됩니다. 카운트가 큰 경우
1보다 크면 ftrace_ops_list_func () 일 가능성이 높습니다.

함수의 콜백이 다음과 같은 트램폴린으로 점프하는 경우
표준 트램폴린이 아닌 콜백에만 해당
그것의 주소뿐만 아니라 function이 인쇄됩니다
트램폴린 전화.

  function_profile_enabled :

설정하면 function 중 하나를 사용하여 모든 function을 사용할 수 있습니다
trace 프로그램 또는 function 그래프 trace 프로그램 (구성된 경우) 그것은
호출 된 함수 수의 히스토그램을 유지
함수 그래프 tracer가 구성된 경우에도
해당 function에 소요 된 시간을 trace합니다. 히스토그램
파일에 내용을 표시 할 수 있습니다.

trace_stats/function  (function0, function1 등).

  trace_stats :

다른 trace 통계를 보유하는 디렉토리입니다.

  kprobe_events :
 
동적 trace 점을 활성화합니다. kprobetrace.txt를 참조하십시오.

  kprobe_profile :

동적 trace 점 통계. kprobetrace.txt를 참조하십시오.

  max_graph_depth :

function 그래프 tracer와 함께 사용됩니다. 이것은 최대 깊이입니다
함수로 trace됩니다. 이것을 값으로 설정
하나는 호출 된 첫 번째 커널 함수 만 표시합니다
사용자 공간에서.

  printk_formats :

이는 원시 형식 파일을 읽는 도구를위한 것입니다. 이벤트가
링 버퍼는 문자열을 참조하지만 문자열에 대한 포인터 만
문자열 자체가 아닌 버퍼에 기록됩니다. 이것은 방지
그 문자열이 무엇인지 아는 도구. 이 파일은 문자열을 표시합니다
도구가 포인터를 무엇에 매핑 할 수 있도록하는 문자열 주소
끈이 있었다.

  saved_cmdlines :

작업의 pid 만 trace 이벤트에 기록됩니다
이 이벤트는 구체적으로 작업을 저장합니다. Ftrace
pid 매핑 캐시를 통신에 표시하여 표시하려고합니다.
이벤트에 대한 통신. 통신에 대한 pid가 표시되지 않으면
출력에 "<...>"가 표시됩니다.

"record-cmd"option이 "0"으로 설정되면 작업이 시작됩니다
녹화 중에는 저장되지 않습니다. 기본적으로 활성화되어 있습니다.

  saved_cmdlines_size :

기본적으로 128 개의 통신이 저장됩니다 (위의 "saved_cmdlines"참조). 에
캐시 된 통신량 증가 또는 감소, 에코
이 파일에 캐시 할 통신의 수로.

  saved_tgids :

"record-tgid"option이 설정된 경우 각 스케줄링 컨텍스트 전환
작업의 작업 그룹 ID는 PID를 매핑하는 테이블에 저장됩니다.
스레드를 TGID로 기본적으로 "record-tgid"option은
비활성화 됨.

  스냅 사진:

"스냅 샷"버퍼를 표시하고 사용자에게
현재 실행중인 trace의 스냅 샷을 만듭니다.
자세한 내용은 아래의 "스냅 샷"섹션을 참조하십시오.

  stack_max_size :

스택 tracer가 활성화되면
발생한 최대 스택 크기.
아래의 "스택 trace"섹션을 참조하십시오.

  stack_trace :

가장 큰 스택의 스택 백 트레이스가 표시됩니다.
스택 trace 프로그램이 활성화 될 때 발생했습니다.
아래의 "스택 trace"섹션을 참조하십시오.

  stack_trace_filter :

이것은 "set_ftrace_filter"와 비슷하지만
스택 trace 프로그램에서 확인할 function

  trace_clock :

이벤트가 링 버퍼에 기록 될 때마다
"타임 스탬프"가 추가되었습니다. 이 스탬프는 지정된
시계. 기본적으로 ftrace는 "로컬"시계를 사용합니다. 이
시계는 매우 빠르며 CPU 당 엄격하지만 일부는
시스템은 다른 것과 관련하여 단조로울 수 없습니다
CPU. 즉, 로컬 시계가 동기화되지 않았을 수 있습니다
다른 CPU의 로컬 시계와 함께.

trace을위한 일반적인 시계 :

  # cat trace_clock
  [로컬] 글로벌 카운터 x86-tsc

  주위에 대괄호가있는 시계는
  사실상.

  로컬 : 기본 클럭이지만 CPU간에 동기화되지 않을 수 있음

  global :이 시계는 모든 CPU와 동기화되어 있지만
     로컬 시계보다 약간 느립니다.

  counter : 이것은 전혀 시계가 아니라 말 그대로 원자
      계수기. 하나씩 계산하지만 동기화됩니다.
   모든 CPU와 함께. 이것은 필요할 때 유용합니다
   주문 이벤트가
   서로 다른 CPU에서 서로.

 runtime : 지피 카운터와 타임 스탬프를 사용합니다.
     부팅 이후 시간과 관련이 있습니다.

  perf : 이것은 ftrace가 perf가 사용하는 것과 같은 시계를 사용하게합니다.
   결국 perf는 ftrace 버퍼를 읽을 수 있습니다
데이터 인터리빙에 도움이됩니다.

  x86-tsc : 아키텍처는 자신의 시계를 정의 할 수 있습니다. 에 대한
      예를 들어, x86은 여기에서 자체 TSC 사이클 클럭을 사용합니다.

  ppc-tb : powerpc 타임베이스 레지스터 값을 사용합니다.
  이것은 CPU간에 동기화되어 있으며 사용할 수도 있습니다
  하이퍼 바이저/게스트 전체의 이벤트를 연관시키는 경우
  tb_offset이 알려져 있습니다.

  mono : 고속 모노 토닉 시계 (CLOCK_MONOTONIC)를 사용합니다.
단조롭고 NTP 속도 조정이 적용됩니다.

  mono_raw :
이것은 원시 단조로운 시계입니다 (CLOCK_MONOTONIC_RAW)
montonic이지만 요금 조정이 적용되지 않습니다.
하드웨어 클럭 소스와 동일한 속도로 틱합니다.

  boot : 이것은 부팅 시계 (CLOCK_BOOTTIME)이며
빠른 단조로운 시계뿐만 아니라 시간 소비
매달다. 시계 액세스는 다음 용도로 사용하도록 설계되었으므로
일시 중단 경로를 trace하면 일부 부작용이 발생할 수 있습니다
일시 중단 시간 이후에 시계에 액세스 한 경우
빠른 모노 클럭이 업데이트됩니다. 이 경우 시계 업데이트
평상시보다 약간 더 빨리 발생하는 것으로 보입니다.
또한 32 비트 시스템에서 64 비트 부팅 오프셋이 가능할 수 있습니다.
부분 업데이트를 봅니다. 이 효과는 드물고 포스트
처리 할 수 ​​있어야합니다. 의 의견을 참조하십시오
자세한 내용은 ktime_get_boot_fast_ns () 함수를 참조하십시오.

시계를 설정하려면 시계 이름을이 파일에 에코하십시오.

  에코 전역> trace_clock

  trace_marker :

이것은 사용자 공간을 동기화하는 데 매우 유용한 파일입니다
커널에서 이벤트가 발생합니다. 문자열 쓰기
이 파일은 ftrace 버퍼에 기록됩니다.

응용 프로그램에서 시작시이 파일을 여는 것이 유용합니다
응용 프로그램의 파일 설명자를 참조하십시오.
파일.

void trace_write(const char *fmt, ...)
{
va_list ap;
char buf[256];
int n;

if (trace_fd < 0)
return;

va_start(ap, fmt);
n = vsnprintf(buf, 256, fmt, ap);
va_end(ap);

write(trace_fd, buf, n);
}

start:

trace_fd = open("trace_marker", WR_ONLY);


  trace_marker_raw :

이것은 위의 trace_marker와 유사하지만 이진 데이터 용입니다.
도구를 사용하여 데이터를 구문 분석하는 데 쓸 수있는
trace_pipe_raw에서.

  uprobe_events :
 
프로그램에 동적 trace 점을 추가하십시오.
uprobetracer.txt 참조

  uprobe_profile :

Uprobe 통계. uprobetrace.txt 참조

  instance :

이것은 다른 곳에 여러 trace 버퍼를 만드는 방법입니다
이벤트는 다른 버퍼에 기록 될 수 있습니다.
아래의 "instance"섹션을 참조하십시오.

  이벤트 :

trace 이벤트 디렉토리입니다. 이벤트 trace 점을 보유합니다.
컴파일 된 (정적 trace 점이라고도 함)
커널로. 존재하는 이벤트 trace 점을 보여줍니다.
시스템별로 그룹화하는 방법 "활성화"가 있습니다
trace 점을 사용할 수있는 다양한 레벨의 파일
그들에게 "1"이 쓰여질 때.

자세한 내용은 events.txt를 참조하십시오.

  set_event :

이벤트를이 파일로 에코하면 해당 이벤트가 활성화됩니다.

자세한 내용은 events.txt를 참조하십시오.

  available_events :

trace에서 사용할 수있는 이벤트 목록입니다.

자세한 내용은 events.txt를 참조하십시오.

  hwlat_detector :

Hardware Latency Detector 디렉토리.
아래의 "하드웨어 대기 시간 감지기"섹션을 참조하십시오.

  per_cpu :

이는 trace per_cpu 정보가 포함 된 디렉토리입니다.

  per_cpu/cpu0/buffer_size_kb :

ftrace 버퍼는 per_cpu로 정의됩니다. 즉, 별도가 있습니다
쓰기를 원자 적으로 수행 할 수 있도록 각 CPU에 대한 버퍼
캐시 수신 거부가 없습니다. 이 버퍼는 다를 수 있습니다
크기 버퍼. 이 파일은 buffer_size_kb와 유사합니다
파일이지만 버퍼 크기 만 표시하거나 설정합니다.
특정 CPU. (여기서는 cpu0).

  per_cpu/cpu0/trace :

이것은 "trace"파일과 유사하지만 표시 만됩니다.
CPU에 특정한 데이터. 쓰면, 그것은 단지 지 웁니다
특정 CPU 버퍼

  per_cpu/cpu0/trace_pipe

이것은 "trace_pipe"파일과 유사하며,
읽지 만 특정 데이터 만 표시하고 소비합니다.
CPU를 위해.

  per_cpu/cpu0/trace_pipe_raw

ftrace 링 버퍼 이진 형식을 구문 분석 할 수있는 도구의 경우
trace_pipe_raw 파일을 사용하여 데이터를 추출 할 수 있습니다
링 버퍼에서 직접. splice ()를 사용하여
시스템 호출, 버퍼 데이터를 신속하게 전송할 수 있습니다
서버가 파일을 수집하는 파일 또는 네트워크
데이터.

trace_pipe와 마찬가지로, 이것은 여러 곳에서 소비하는 독자입니다.
읽기는 항상 다른 데이터를 생성합니다.

  per_cpu/cpu0/스냅 샷 :

이것은 기본 "스냅 샷"파일과 유사하지만
현재 CPU 스냅 샷 (지원되는 경우). 표시 만
주어진 CPU에 대한 스냅 샷의 내용
이 CPU 버퍼 만 지 웁니다.

  per_cpu/cpu0/snapshot_raw :

trace_pipe_raw와 유사하지만 이진 형식을 읽습니다.
주어진 CPU에 대한 스냅 샷 버퍼에서

  per_cpu/cpu0/stats :

링 버퍼에 대한 특정 통계가 표시됩니다.

 항목 : 여전히 버퍼에있는 이벤트 수입니다.

 오버런 : 덮어 쓰기로 인해 손실 된 이벤트 수
    버퍼가 가득 찼습니다.

 커밋 오버런 : 항상 0이어야합니다.
  중첩 된 이벤트 내에서 너무 많은 이벤트가 발생하면 설정됩니다.
이벤트 (링 버퍼가 다시 입력 됨)
버퍼링하고 이벤트 삭제를 시작합니다.

 바이트 : 실제로 읽은 바이트 수 (덮어 쓰지 않음).

 가장 오래된 이벤트 ts : 버퍼에서 가장 오래된 타임 스탬프

 이제 ts : 현재 타임 스탬프

 삭제 된 이벤트 : 덮어 쓰기 option이 해제되어 이벤트가 손실되었습니다.

 

 

반응형
반응형

이번에는 생애주기 별 자가 구입방법에 대해서 적어보고자 합니다.

 

물론 이 내용은 저의 경험을 바탕으로 작성된 내용이니 참고로만 이해해주시기 바랍니다. 

 

요새같이 집값이 하늘 높은 줄 모르고 뛰어오르고 있는 이 때 제가 집을 구입한 방법과 여러 사람들의 방법을 종합해서 케이스 별로 정리를 간단하게 해보겠습니다. 

 

- 청약 

가장 쉬운 방법이지만 어쩌면 가장 어려운 방법일 수 도 있습니다. 다들 잘아시겠지만 청약은 포인트를 만족시키기가 너무 어렵고 또한 추첨이라는 변수가 존재하기 때문에 크게 다루지는 않겠습니다.

 

- 결혼준비 기간

결혼 준비를 하시는 분들은 잘 읽어주시기 바랍니다. 사실 20대 후반 부터 30대 초-중반에서 가장 큰 자금을 다룰수 있는 기간입니다. 그렇다면 어떻게 결혼준비 기간의 집을 구매할 수 있나 알아보겠습니다. 기본적인 방법은 갭투자 방법을 따르게 됩니다. 통상적으로 결혼준비는 최소 3개월에서 최대 1년까지 걸리게 됩니다. 

 

그럼 어떻게 하냐... 결혼준비를 바꿔서 생각하면 자가구입 가능 기간이라고 생각할 수 있습니다. 그렇다면 예비 부부간의 합의하에 자가 구입이 가능할 수 있습니다. 통상적으로 아파트 매매 물량 중에는 전세가 현재 살고 있는 집들이 있습니다. 보통 이런 매물들이 급매라는 이름으로 나오게 됩니다. 

 

전세를 내놓은 집주인이 갑자기 급전에 필요해서 내놓는 경우가 많습니다. 특히나 요새 같이 갭투자가 많이 되고 있는 상황에서는 이런 물량은 더 많을 수 있겠죠 또한 이런 매물일 경우 집값의 흥정 또한 될 가능성도 많이 있겠죠. 

 

그렇게 집을 구매 해놓으면 나머지는 살면서 채워넣는 방법으로 결혼 준비를 할 수 있겠죠. 사실 이 방법을 많은 사람들이 선호할 수 있을지는 모르겠습니다. 그렇지만 이 방법이 결혼생활 시작과 동시에 자가구매를 할 수 있는 좋은 방법인거 같아서 적어보았습니다.  

 

 

- 전세에서 자가로

전세를 살고 있는 방법은 크게 2가지가 있습니다. 하나는 집주인으로 부터 살고 있는 집을 그대로 매매하는 방법입니다. 이럴경우 이사비용 및 기타 비용을 최소한으로 줄여서 할 수 있는 방법입니다. 물론 이 경우에는 전세 계약 전 집주인에 대한 디테일한 이해와 부동산 중개업자의 총평을 통해 구매할 수 있고 2년 동안 살아온 집을 매매하는 거라 집에 대한 만족도 또한 좋을거라 생각됩니다.

 

또 다른 방법은 전세를 살고 있으면서 집을 구매하는 방법입니다. 이것 역시 첫번째 말씀드린 결혼준비 하는 기간에 집을 구매하는 방법과 유사한 방법입니다. 통상적으로 전세자금 대출과 주택담보 대출을 비교했을 때 주택담보 대출이 훨씬 부담이 많이 됩니다. 전세자금 대출은 기본적으로 이자만 내는 방법으로 운용이 가능하지만 주택담보 대출은 원리금을 동일하게 상환해야 된다는 부담이되죠. 

 

사실 이 방법의 대 전제는 집값이 내 월급보다 빨리 오르니 집은 빨리 사는게 좋다 라는 조건에 동의한다면 취할 수 있는 방법입니다. 

 

최대한으로 전세자금 대출을 받은 다음에 유휴 자금력을 바탕으로 집을 구매하는 방법입니다. 이럴경우 전세 자금 대출을 주로 갚아 나가게 됩니다. 다시말해 이자만 갚아나가는 구조로 대출을 바꿔지게 됩니다. 이를 통해 2년이라는 시간을 벌게 됩니다. 그리고 2년 후 자신의 재산 및 재무 상태를 비교 해서 집에 입주여부를 정하게 됩니다. 

 

이게 어떤 이득을 주게 되는가 하면, 2년 후의 집 값은 2년 전 보다 많이 오르기 때문에 상대적인 이득을 얻게 됩니다.

 

이상 저의 경험을 바탕으로 집을 구매 할 수 있는 방법에 대해 적어보았습니다.

 

 

 

 

반응형
반응형

Buffers와 cached 영역

커널은 블록디바이스(디스크)로부터 데이터를 읽거나 사용자의 데이터를 디스크에 저장한다. 하지만 디스크는 다른 장치에 비해 매우 느리기 때문에 디스크에 요청을 기다리는 시간이 상당히 많이 소요되고, 이로 인해 시스템에 부하가 발생하게 된다.

 

한번 읽은 디스크의 내용을 메모리에 저장해 두어서 동일한 내용을 읽고자 하면 다시크로 요청하지 않고 메모리에 저장해 두어서, 동일한 내용을 일고자 한다면 디스크로 요청하지 않고 메모리오 요청하게 되는데 이런기능을 캐싱기능이라고 한다

 

이때 사용되는 캐싱영역을 buffers, cached라고 부른는데 이 차이점을 알아보고자 한다.

 

 

 

Page Cache는 bio 구조체를 만들고 해당 구조체에 디스크로부터 받은 일반적인 데이터를 저장하게 되고 Buffer Cache는 일반적인 데이터가 아닌 _get_blk()와 같은 내부 함수를 통해 데이터가 아닌 super block, inode block 데이터를 저장한다. 정리하면 Page Cache는 파일 내용을 저장하고 있는 캐쉬, Buffer Cache는 파일시스템의 메타 데이터를 담고 있는 블록을 저장한다.

 

서버운영 시간이 길지 않을 때는 가용영역에 있는 메모리의 사용양이 사용영역보다 많게 됩니다. 시간이 조금 지나면 시스템은 가용영역 중 일부를 , 캐쉬영역으로 사용하게 됩니다. 그러나 시간이 지날수록 application에서 사용해야 되는 사용영역이 늘어나게 되면 일부 캐쉬영역을 반환해서 사용영역으로 반환하게 된다, 이렇게 지나고 캐쉬영역이 사용할 메모리 공간이 없어지게 되면 시스템 swap 영역을 사용하게 되고 그 순간부터 시스템 성능이 줄어들게 됩니다. 이처럼 buffers와 cached는 시스템의 I/O 성능 향상을 위해서 커널이 사용하는 영역입니다.

 

/proc/meminfo 읽기

root@choi:~# cat /proc/meminfo

MemTotal: 16305588 kB

MemFree: 366592 kB

MemAvailable: 15282500 kB

Buffers: 7065240 kB

Cached: 8024384 kB

SwapCached: 196 kB

Active: 5018828 kB

Inactive: 10413956 kB

Active(anon): 220168 kB

Inactive(anon): 223656 kB

Active(file): 4798660 kB

Inactive(file): 10190300 kB

Unevictable: 16 kB

Mlocked: 16 kB

SwapTotal: 2097148 kB

SwapFree: 2087420 kB

Dirty: 812 kB

Writeback: 0 kB

AnonPages: 343028 kB

Mapped: 242032 kB

Shmem: 100664 kB

Slab: 388140 kB

SReclaimable: 262456 kB

SUnreclaim: 125684 kB

KernelStack: 6288 kB

PageTables: 27120 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 10249940 kB

Committed_AS: 2933680 kB

VmallocTotal: 34359738367 kB

VmallocUsed: 0 kB

VmallocChunk: 0 kB

HardwareCorrupted: 0 kB

AnonHugePages: 2048 kB

ShmemHugePages: 0 kB

ShmemPmdMapped: 0 kB

CmaTotal: 0 kB

CmaFree: 0 kB

HugePages_Total: 0

HugePages_Free: 0

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

DirectMap4k: 941696 kB

DirectMap2M: 15716352 kB

SwapCached : SwapCached는 SWAP으로 빠진 영역 중 다시 메모리로 돌아온 영역입니다. 시스템에 메모리가 부족하면 커널은 프로세스의 주소공간 중 swap영역으로 이동시킬 수 있는 메모리를 선택해서 swap 영역으로 이동시킨다. 이 과정에서 I/O가 일어나기 때문에 성능저하가 발생한다. 그 후 메모리가 확보되어 swap영역으로 빠졌던 영역이 다시 메모리로 돌아가더라도 지우지 않고 이후에 발생할 수 있는 메모리 부족현상을 대비해서 이전에 내용을 지우지 않습니다.

 

Active(anon) : 특정 파일 내용을 저장하고 있는 Page Cache 영역을 제외한 메모리영역을 의미 한다. 주로 프로세스들이 사용하는 메모리 영역을 지칭하며, 그중에서도 비교적 최근에 메모리영역이 참조되어 swap 영역으로 이동되지 않을 메모리 영역을 의미한다.

 

Inactive(anon) : Active(anon)와 동일영역, 비교적 참조한지가 오래되어 swap으로 이동할 수 있는 메모리 영역

 

Active(file) : anon과 다르게 file로 되어 있는 이 영역은 커널이 I/O 성능 향상을 위해 사용된는 영역을 의미한다. buffer와 cached가 여기에 속한다. 최근에 참조되어 swap영역으로 이동되지 않을 메모리 영역이다.

 

Inactive(file) : Active(file)과 비슷한 용도로 사용, 비교적 참조 된지 오래되어 swap 영역으로 내려 갈 수 있는 영역이다.

 

Dirty : I/O 성능향상을 위해 커널이 캐시 목적으로 사용하는 영역 중 쓰기 작업 이 이루어져서 실제 블록 디바이스 드라이버에 씌어져야 할 영역을 의미한다. 커널은 기본적으로 I/O 쓰기 요청이 들어오면 바로 블록 디바이스 드라이버에 내리지 않고 일정량이 될 때까지 모았다가 지연쓰기를 한다.

 

slab : 메모리 영역 중 커널이 직접 사용하는 영역을 Slab 영역이라고 한다. 이 영역에는 dentry cache, inode cache등 커널이 사용하는 메모리가 포함된다.

 

SReclaimable : slab 영역 중 재사용 될 수 있는 영역이다. 캐시 용도로 사용되는 메모리들이 주로 여기에 포함된다. 메모리 부족현상이 일어나면 해제되어 프로세스에 할당 될 수 있는 영역이다.

 

SUnreclaim : slab 영역 중 재사용 될 수 없는 영역이다. 커널이 현재 사용중인 영역이며 해제해서 다른 용도로 사용할 ㅅ없다.

반응형
반응형

※ 리눅스 스케줄링 구현 

CFS의 4가지 구성요소

- 시간 기록

- 프로세스 선택

- 스케줄러 진입 위치

- 휴면 및 깨어남

 

시간 기록

1 모든 프로세스 스케줄러는 각 프로세스의 실행 기록을 기록

2 대부분 유닉스 시스템은 프로세스에 타임슬라이스를 할당하면서 기록

3. CPU 클럭 한틱이 지날때마다 그틱에 해당하는 시간만큼 타임슬라이스가 줄어든다

 

스케줄러 단위 단위 구조체

1 CFS에는 타임슬라이스 개념이 없지만 공정하게 할당된 몫만큼을 사용하기 때문에 프로세스의 실행시간을 기록해 두어야 한다.

2 <linux/sched.h>에 정의된 struct sched_entity라는 스케줄러 단위 구조체를 사용해서 정보를 저장

 

가상실행 시간

1. vruntime 변수에는 프로세스의 가상 실행시간이 저정되며 가상 실행시간은 실행 가능한 프로세스 개수에 따라 정규화한 실제 실행시간을 의미한다.

2. 가상실행시간을 이용해 CFS가 지행하는 '이상적인 멀티태스킹 프로세서'를 근사적으로 구현 가능

이상적인 프로세서에서는 우선순위가 같은 프로세스의 가상 실행시간은 3. 모두 같으며 CFS는 vruntime을 통해 프로세서가 얼마나 오랫동안 실행 됬는지 앞으로 얼마나 더 실행되어야 하는지를 기록

4. 이작업은 kernel/sched_fair.c에 정의된 update_curr()에서 수행

 

프로세스 선택

1. 다음 실행할 프로세스를 선택할 때 CFS는 vruntime이 가장 작은 프로세스를 선택

2. CFS는 이를 효율적으로 하기 위해 레드블랙트리를 사용한다 (rbtree)

3. 레드블랙트리는 어떤 데이터를 노드에 저장하는 자료구조로, 특정키로 각 노드를 식별할 수 있으며, 키값이 주어졌을 때 그 키값을 가진 데이터를 효율적으로 탐색할 수 있는 자료구조

 

다음 작업 선택

1. 시스템의 실행가능한 모든 프로세스에 대해 각 프로세스별로 가상 실행시간을 키값으로 하는 노드를 만들어 레드블랙를 구성했을 때,

2. 주어진 트리에서 vruntime값이 가장 작은 CFS가 다음에 실행하고자 하는 프로세스는 트리의 가장 왼쪽에 있는 노드에 해당하는 프로세스

3. 트리의 루트노드에서부터 말단 노드에 이를 때 까지 계속 왼쪽 노드를 다라 가면 vruntime 값이 가장 작은 프로세스를 찾을 수 있다.

4. 따라서, CFS의 프로세스 선택 알고리즘은 "레드블랙트리의 가장 왼쪽노드에 해당하는 프로세스를 실행한다"로 요약

( kernel/sched_fair.c __pick_next_entity() 가 수행)

 

스케줄러 진입 위치

1. 프로세스 스케줄링 작업을 시작하는 곳은 kernel/sched.c 파일의 schedule()함수에 정의

2. 커널의 다른 부분에서 이 함수를 통해 프로세스 스케줄러를 호출함으로서 다음에 실행할 프로세스를 선택하고 실행

3. schedule()함수는 더 일반적인 형태의 스케줄러 클래스이고 이 함수는 가장 우선순위가 높은 실행 가능한 프로세스를 가진 스케줄러 클래스를 찾고 다음에 실행할 프로세스를 해당 스케줄러에게 물어본다.

4. kernel/sched.c 파일의 pick_next_task()함수는 가장 높은 우선순위의 스케줄러 클래스부터 돌아가면서 우선순위가 가장 높은 클래스의 우선순위가 가장 높은 프로세스를 찾아낸다.

 

반응형

+ Recent posts