process and thread =>power 7 system

Agenda 

Unit 1 – Processor Resources

Unit 2 – Process Management Framework

Unit 3 – Scheduling and Dispatching

Unit 4 – Monitoring Processor Utilization

Unit 5 – Synchronization Mechanisms

 

Unit 1. Processor Resources

 

Big Picture POWER7 System

power7 processor 의 multi-core architecture 는 throughput(처리량),efficiency(효율),scalability(확장성),RAS 등의 기술 리드를 하고 있다. 또한 processor와 다른 element, facilities는 maximum throughput을 위해  balanced되어야 한다. 

throughput(처리량) – bandwith 랑 헷갈릴 수 있는데 bandwidth는 최대 처리 할 수 있는 양이고 throughput은 해당 bandwidth를 최대로 사용하여 처리 할 수 있는 처리 량이라 보면 좋겠다.

efficiency(효율) – 가용성이라 보면 적당할듯, 

scalability(확장성) – 사용량 증대에 따라 유연하게 대응하는 능력

RAS  – Reliability : 신뢰도, 얼마나 드물게 fault 나 defect이 있는지

             Availability: 가용성, 얼마나 드물게 application이 defect나 fault에  functionaly 영향을 받는가

             Serviceablity : 내구성, 장애 발생시 이를 얼마 잘 메니지 되는가, 관리자에게 잘 inform해주고, infact없이 잘 repaired되는가

 

 

Logical partitions

 

Logical partition을 통해 하나의 system에 여러개의 OS를 올릴 수 있게된다. 각각의 partition을 개별적으로 동작하고 개별적인 OS를 올릴 수 있다 .이 OS에 올라가는 application또한 완전히 개별적으로 돈다.

partition은 logical이다. partition에 할당되는 hardware는 physical boundaries에 있지 않다. lpar끼리 물리적인 동작 없이 resource를 옮길 수도 있는 architecture이다.

이런 동작이 가능한 이유가 power hypervisor가 있기 때문이다.

 

POWER Hypervisor Functions

orchestrate 와 virtualization manage를 한다.

– physical resource를 lapr에 따라 나눈다.

– lpar 사이의 security와 isolate를 한다.

– 필요시 dynamic하게 resource를 reconfiguration한다.

– virtual console을 support한다.

 

partition들은 각각이 분리 되어 있다. power hypervisor라 불리는 firmware에 의해서..

partition memory와 i/o memory 사이의 program access는 불가능 하다.

program의 exception , crash등은 온전히 lpar내에서 발생한다. hypervisor는 partition에 따른 page table을 관리한다. partition은 오직 본인의 physical memory segment에만 접근된다.

이것은 physical memory의 offset 값을 사용한다. 그래서 각각의 partitoon에 있는 os는 memory를 0부터 시작 할 수 있다.

이말이 좀 어려운데..모든 os가 동일한 메모리 번호를 가질 수 있다는 말이다. 실제 physical 메모리에는 서로다른 위치에 있을지 모르지만 os입장에서는 모두 0부터 메모리를 쓰게 되는 거다. 이런 것이 가능한 이유가 바로 hypervisor가 있기 때문이다.

 

hypervisor는 HMC에서 실행되는 virtual console에 대해서 input/output streem을 제공한다. 

virtual memory 관리 측면에서, hypervisor는partition이 오직 할당된 device에만 access하는것을 보장한다.

hypervisor는 resource가 partition에 할당되면 memory를 clear하고,processor를 reinitialize 하고, processor register를 reset하고, i/o device를 reset한다.

 

Partition Resources

Lpar는 resource 할당에 flexibility 를 제공한다.

각각의 Lpar는 고유의 OS, virtual resource set (processor, memory, i/o, clock,console)

각각의 partition에서는 고유의 os가 설치되고, os version 은 system에서 support 되는 것이어야 한다.  

각 partition 은 일부 physical system 속성을 share하는데 , system serial nuber, modle, processor feature code 등이 같다.

또한 원한다면 SCSI device 도 share가능하다. (jh 생각: scsi를 share한다는 것은 disk 하나를 여러 lpar가 공유한다는 의미는 아닌듯 하고, 하나의 scsi contoller는 여러 disk를 관리 하니 이 disk를 여러 lpar에 각각 줄 수 있다. 그러므로 scsi contoller를 공유한다는 의미로 쓰인것 같다)

 

System resources

system resource 에는 processor , memory, i/o slot 등이 있다. i/o slot 이 할당될때 solot 단위로 된다. 이말은 여러 device들이 slot 에 연결되면 해당 slot이 할당되는 개념이니까 그 deivice가 할당된다는 거다. 이런 concept가 있어서 다양한 device를 효율적으로 배치 해 쓸 수 있다.

 

POWER7 Processor

Multi-core processor  – 최대 8 core  per socket

SMT 지원 (simultaneous multithreading)  – 최대 4개의 hardware thread가 한 core에서 동시에 run 할 수 있다.

(내생각)=> core 하나는 4 way로 구성 할 수 있고 (SMT가 enable되어 있을 경우), 이 말은 한 core에서 동시에 4개의 hardware thread를 처리 할 수 있다는 것이다. 한 칩에는 multi core로 최대 8개 core가 있을 수 있고(MHD,MMD모델 각 core는 four way로 configure 할 수 있으므로 32 thread를 동시에 처리 할 수 있다는 계산이 나온다. (물론 구성에 따라 다를 수 있겠지..)

 logical processor per core

-dedicate processor를 가진 Lpar 에서 logical processor는 physical cpu의 4배가 된다.

-shared processor를 가진 Lpar에서  logical processor는 virtual processor 개수의 4배가 된다.

(내생각)=> shared 이든 dedicate이든 os 입장에서 보면 모두 4way로 동작 할 수 있다는 말이다. physical cpu 란 core 하나 단위를 말한다. physical하게 allocation할 수 있는 것은 core단위 이기 때문이다. 고로 core하나를 4 way로 동작하게 할 수 있고 이는 OS입장에서 

 

power7은 multi-core architecture는 최대 8core (physical processor) 로 구성된다. (on a single slice of silicon)

(내생각)=>chip하나에 8개의 core를 가질 수 있는거다.  근데 모든 power7 processor 이 core를 8개 갖는 chip인것은 아니다. 최대 8core이란 의미이다. 

 

각 hardware thread는  분리된 logical processor에 의해 처리 된다. 이 processor는 OS에서 관리한다. 그렇기에, dedicated partition ( 하나의 physical processor가 할당되는 것) 은 OS에 의해  logicaly  two way 또는 four way 로 동작한다. SMT(simultaneous multithreading) 이 enable되어 있어야 가능하다.

이것은 partition type에 독립적이다. 고로,하나의  virtual processor를 가진 shared partition  또한 logical two -way 또는 four-way로 구성된다.

AIX에서 SMT 는 default enable상태 이다.

 

 

 

 

 

Processor Virtualization

 

 

 

virtual processor 는다른 partition과  share되는 logical processor 의 일부 percentage를 점유한다.

 

physical processor 는 2 or 4 logical processor 로 구성될 수 있다 ( SMT mode enable되었을 때만 됨) 

만일 SMT 가 disable이면 one physical processor 는 one logical processor와 mapping되고 한번에 하나의 thread만 처리 할 수 있다.

 

shared processor는 해당 lpar에 할당된 physical processor 를 time slice 하여 일정 percentage를 점유하게 된다.

 

dedicated processor는 모든 physical processor를 하나의 특정 partition에 모두 할당 하는 것을 말한다. core단위로 할당이 가능하다.

 

 

Dedicated Processors and Shared Processors

 

 

 

partition 은 dedicated processor와 shared processor 중 아무거나 이용해 구성 할 수 있다.

dedicated processor는 모든 physical processor 를 특정 partition에 할당한다. partition이 shut down되면 해당 processor 는 shared rpocessing pool에 return된다. dedicated processor 로 구성된 parttion이 다시 시작하면 다시 dedicated processor가 된다. 실제적으로 activate되는 physical processor는 예전에 구성되었던 놈과 다를 수 도 있다.

 

shared processor는 physical processor를 time slice를 기반으로 partition에 할당된다. physical processor 는 shared processor pool에 들어가 있고 , partition의 실행 요청에 따라 , 그게 어느 partition이 됐든 자원을 주게 된다. shared processor pool은 오직 하나다.( 새로나온 9179 system은 그렇지 않았던것 같다..분명히 shared processor pool이 10개 넘게 있었다. hmc 7.9를 사용하는 그 system)

 

Processor affinity

system은 processor와 memory 를 마지막으로 할당되었던 dedicated processor partition에 주려고 한다.

그전 기록을 가진 parttion에 주는게 가장 효과 적이기에 이런 priority를 주는 것 같다. 절대적이진 않고 우선순위가 높을 뿐인것

 

Shared Processors and Virtual Processors

virtual processor 는 logical processor의 percentage로 나눈 unit이다. logical processor는 물론 다른 partition과 공유한다.

virtual processor의 개수는 OS입장에서는 physical processor로 생각한다. VP의 개수는 shared processor를 사용하는 각각의 partition이 따로 고유하게 구성할 수 있다. VP setting 으로 총 processing unit이 바뀌지는 않는다.

최대 VP개수는 Power7에서는 256개 이다.  vp의 setting에서 동시에 처리 할 수 있는 thread 개수를 지정할 수 있다. 위 이미지는 example을 보여주는데. 6개의 physical processor 가 shared processor pool에 할당되어 있고 이게 8개의 vp로 구성되어 2개의 partition에 할당되었다.

 

Entitled Capacity (지정된 용량)

 

 Entitled Capacity라 함은 lpar에게 보장되는 processing 개수 이다.

– dedicated and shared processor partition모두에 해당 한다.

 

shared processor partition은 Capped or uncapped로 구성될 수 있다.

-capped : entitled capacity가 제한된다. 예를 들어 1.5 capped processing unit이라 함은 partition 은 최대 15ms 를 가질 수 있다는 거다. time slice에서…

-Uncapped : 만약 partiton이 추가적인 processing cycle 이 필요하다면(entitled capacity를 넘어서는 ..) shared pool에서 놀고 있는 리소스를 가져다 쓸 수 있다. 예를들어 1.5 uncapped partiton unit이라 함은 1.5 unit을 보장하고 필요시 더 가져다 쓸 수 있다는 말이다. 

 

entitled capacity는 두가지의 중요한 factor로 정의된다.lpar는 어떤 시점에서 얻을  CPU cycle 을 보장한다.  그리고 untilization 통계 에대한 측정의 base unit 을 보장한다. => 어렵게 써 놓긴 했는데… 쉽게 말해.. 최소 resource 양을 보장한다는 말이다.

managed system의 관점에서 entitled capacity 란  system에서 사용되지 않는   total entitled capacity 의 physical processor의 개수 이다.

 => 쉽게 풀면 , managed system관점에서 entitled capacity란 아직 사용되고 있지 않는 physical processor의 total인 거다.

이 말은 managed system의 모든 lpar는 어떤 시점에든 entitled capacity 를 쓸 수 있단거다.

 lpar 가  one dispatch cycle(10ms) 내에  사용할 수 있는 capacity가 보장된다. 

 

=> 위 말이 너무 어려우니 다시 내 맘대로 정리 하면…

lpar는 cpu cycle을 보장한다.

entitled capacity의 관리 측면에서 보면 총 entitled capacity는 physical processor 수를 넘길 수 없다. 이말은 모든 lpar는 어떤 시점에서 entitled capacity를 사용할 수 있다는 말이다. capcity는 one dispatch cycle이 10ms 기준으로 lpar에 보장된다.

 

shared processor partition은 capped 또는 uncapped로 구성 될 수 있다. capped partition은 너가 해당 partitioon이 얼마나 일할지 측정 가능할때 

사용하면 효율적이다. 만일 0.2 processing unit으로 구성하면 최대 processing capacity는 20% 가된다. 그러니까 10ms단위로 나뉘니까 10ms의 20%를 사용하게 된다는 거다. capped 로 하면 이 이상 넘어가지 않는다. 만일 이것을 uncapped로 하면 shared process pool 에 있는 여유 resource만큼 over해서 사용 할 수 있다.

 

page 23부터…

Shared Processor Pool (1 of 2)

 

각 partition은 10ms timeslice의 실행 time percentage를 가져감으로서 shared processor 환경에서 lpar를 구성한다.

 

example

– 0.2 processing unit 이라하면 10ms 의 20%를 가져간다는 의미이다.

– 1.8 processing unit이라 하면 10ms의 180%를 가져 간다는 의미다. ( 180%사용률이라 함은 multiple processor를 사용함으로 가능한 수치이다)

  이 말은 2개의 processor를 9ms 씩 사용한다면 10ms 기준으로 180%가 나오게 된다.

 

 

hypervisor 는 idel time이 넘는 것을 다시 pool에 돌려준다.

=> 이말은 남는 시간만큼 다른 lpar가 가져갈 수 있게 pool에 넘겨준다는 거다.

 

 

 

10ms단위의 실행 시간은 매우 중요한 개념이다. partition이 timeslice를 이용한다, 이는 timeslice의 특정 portition을 차지한다는 의미다. 

예를들어보자

0.5 processing unit이 할당된 partition이 있다고 하자, 이 partition은 10ms의 timeslice에서 5ms를 가져갈거다. 하지만 partition은 5ms의 timeslice를 다 사용못하기도 한다.

i/o wait나 interrrups , processing의 lack등 이 있기 때문이다. 어찌됐든 partition은 최대 5ms의 processing time을 보장한다.

 

만약 partition이 1.0 processing unit이상을 가진다면 이것은 여러개의 physical processor를 utilize해서 사용하게 된다. 

위에 내가 한 설명의 다시 한번 반복하고 있기에 더 설명하지 않겠다.

 

아래 example은 10ms timeslice 를 보여주고,4개의 physical processor 에 7개의 partition이 있다. 

 

위 그림에서 partition1이 동그란 점선으로 표시되고 partition1은 동시에 2개의 physical processor에서 동작함을 알 수 있다.

interrup되거나 return이 되면 resource는 shared processor pool로 돌아간다.

 

Viewing Processor Information

processor list를 보는 명령, physical 이드 virtual이든 관계 없음

#lsdev -c processor

 

processor 속성확인명령

#lsattr -El proc0

 

lpar와 hypervisor의 utilization statistic 정보

#lparstat

 

lsdev -c processor 명령은 os 입장에서 processor list를 보여준다. 

aix의 location code도 출력된다. =>(내생각) 아마도 proc0이 aix location인듯?

만약에 partition이 dedicated processor를 사요하면 lsdev명령에 의해 physical processor가 보여질거다.

shared processro를 사용하면 lsdev는 virtual processor를 보여준다. 

lsattr 명령은 processor의 속성값을 보여준다. smt_enabled속성은 simutaneous multithreading 속성을 말하는 것으로 동시에 여러 processor에서 task처리가 되는지에 대한 속성이다.

lparstat 명령은 lpar 에 관련된 정보를 보여준다.

user% -=> application이나 user 단에서 사용되는 process resource 값이다.

sys% => system이 사용하는것 , 그러니까 kernel이 사용하는 process resource값이다.

wait => i/o wait 하는 process resource 값이다.

idle => 완전히 놀고 있는 process resource값이다.

다른 값들은 정확히 모르겠다.

Viewing Partition Information

lparstat -l 명령으로 더 자세히 partition information확인 가능

 

Virtual Processors Performance

어느정도의 virtual processor를 사용하는게 performance에 최적일까?

– 시작은 작게 하고, monitoring을 통해 점차 늘려가는게 맞다.

 

만일 virtual process가 너무 적거나 많을경우 performance issue가 발생 할 수 있다.

-too low: uncapped partition 은 cycle을 넘는 부분에 대해 adavantage를 가져갈 수 없다.

=>vp가 너무 적다는 말은 processing unit을 소수의 vp에 몰아주는 결과 이고, uncapped 된 lpar에서 남는 리소스를 가져가지 못하게 된다. 왜냐하면 소수의 vp에 resource가 몰려 있기때문인다.

예를들어보자 1.0 processing unit을 1개의 vp에 몰아 줬다고 해보자.

그런데 thread는 5ms명 충분한 상태이다. 그렇지만 하나의 vp가 최소한 10ms를 잡아먹어야 한다. 그럼 5ms를 낭비하게 되는거다. 이것은 pool에 돌려줄 수도 없는 부분인거다. 어찌됐든 vp가 물고 가버렸기에..

이를 다르게 구성해보자. 1.0 processing unit을 2개의 vp에 몰아 줬다고 해보자. 그럼 하나의 vp0가 5ms를 가져가고 이게 thread를 처리하기에 충분하다. 그럼 vp1은 pool에 돌려주고 이를 uncapped lpar가 사용 할 수 있는거다.

 

-too high: context switching이 너무 많이 발생하게 된다.

=>vp가 많기 때문에 vp간에 context switch가 당연히 많이 발생할 것이고 이게 오히려 성능에 나쁜 영향을 주게 된다.

 

aix는 virtual processor 를 fold할 수 있다. 만약 너무 많은 VP들이 있을경우

모니터링을 통해 configuration을 조금씩 조정해 가면서 best configuration을 찾는게 좋다.

 

virtual processor folding : 

virtual processor folding 이란 개념은 aix 5.3 ML 3 부터 생긴 개념이다.  uncapped micro-partiton에서 최대의 adavantage를 가져가기 위해서 고안된 개념이다.

 

=>CPU folding의 원래 의도는, 몇개의 선택된 vcpu에 물리적 core의 computing power를 몰아주면서 불필요한 context switch를 줄임으로써 성능을 더 좋게 만들자는 것입니다.

예를들어 설명해보자

1.0% processing unit을 shared pool에서 특정 lpar에 할당하였고 vp를 4개로 지정했다. 이 말은 달리 해석하면 10ms 의 timeslice를 온전히 한 lpar가 가져간다. 하지만 os입장에서는 4개의 cpu가 있는거다.

그럼 10ms를 4개의 cpu가 나눠 먹어야 하고 (이게 multi threading 개념이니까…) 결국 각 cpu는 0.25ms 씩 돌게 되는거다. 마치 동시에 도는것 처럼 보이겠지만 0.25씩 10ms를 나눠서 도는거다.

그런데 만일 1개의 main runable thread만 있는 application이라면 어떨까?

그럼 이 thread가 vp0 에서 돌고 있다고 가정해보자 . 0.25 ms 돌고 vp1로 넘어간다. 하지만 vp1에는 돌릴 thread가 없다. 왜냐하면 application은 thread가 한개뿐이기 때문이다.

=>(여기는 추측)이때 vp0의 thread를 vp1에서 돌리려면 migrate를 해야한다. vp0에서 수행한 정보를 vp1에 전달하고 또다시 vp1이 0.25ms가 연산을 수행하고 이를 vp2로 migrate하는거다. 

migrate를 하든 아님 자신에게 할당된 thread가 없기때문에 그냥 0.25ms를 날려버리든… 어찌되었든 우리는 1.0%의 processing unit을 가졌음에도 실상 0.25ms만 사용하게 되던가 아님 migrate를 통해 비효율적인 10ms를 사용하게 되는거다.(migrate시간이 들게 될 것이므로 migrate를 통해 4개의 vp를 모두 사용한다 해도 어찌됐든 비효율적이다. context switching 비효율)

이럴땔 cpu folding을 사용하는 거다. folding을 하면 vp1,vp2,vp3의 computing power를 vp0에 몰아 주게 된다. 이렇게 되면 thread 하나를 context switch가 없는체로 10ms를 온전히 사용하게 된다.

이렇게 되면 성능이 올라가게 된다.

단, oracle 이나 sybase등의 ISV에서는 folding기능을 disable하기를 권장한다. 이들 application에서는 os단에서 vp개수를 강제로 줄이게 되면 오히려 성능이 감소 한다고 한다. 왜 더 성능이 감소하는지는 공부가 필요 할듯 하다.

 

위 그림의 수치 값이 의미하는 바가 이해가 안됨

vp * CPU갯수 = EC 

 

(entitlement cpu) ent로 표현되기도 함.

(추측) id= idle, wa=waiting, pc =physical cpu , ec = entitle capacity

 

 

 

Micro-Partitions and Applications

micro – partition이라 함은 shared processor를 이용해 partition을 구성하는 것을 말한다.

그럼 언제 어떤 application일때 micro partition을 사용해야 할까?

평소 cpu 사용율이 낮은 application 인때 가끔 한번씩 peak치는 application . 이를테면 light web application, mail server, directory server등이다.

application입장에선 micro partition이든 아니든 염려할 필요 없다.

그럼 어떤 application은 micro partition이 비효율 적일까?

application에서 transaction의 빠른 response time이 요구 되거나 polling 업무 처리 application , processor의 computing power가 많이 필요한 applicaiton에는 부적합 하다. 

ex ) DSS(decision support system) , HPC(high performance computing)같은 것

 

Simultaneous Multithreading (1 of 2)

4개의 hardware thread가 동시에 처리 될 수 있다 .(power7 1개 chip에는 4개의 processor core가 있다.)

power 7 에는 SMT mode를 지정 할 수 있다. SMT1 ( off), SMT2( 2 threads), SMT4(4threads)

single processor core(한개의 core)는 two 또는 four 개의 logical processor로 os에 보여진다. 

 

Simultaneous multithreading 은 하나의 physical processor 에 하나이상의 thread context를 dispatch하는 기능이다.

physical processor당 두개의 hardware thread가 있기에 동시에 수행가능한거다.

power architecture는 superscalar processor(처리장치가 한 사이클 동안 여러 명령어를 동시에 처리할 수 있게 하는 설계이다.)

 를 지원한다. 이는 동시에 read & run instruction을 처리 할 수 있게 한다. 

이 기능을 통해 두개의 application을 동시에 병렬로 한 processor에 의해 처리 되게 할 수 있다.

 

Simultaneous Multithreading (2 of 2)

 

SMT 는 one thread 에서 긴 대기시간이 발생하면 남는 시간을 다른 thread에 줄 수 있다. 예를들어 하나의 thread에서 cache miss가 있더라도 , 

 

각 hardware thread 는 각각의 logical processor에 의해 지원된다. 고로, dedicated partition 은 한개의  physical processor를 온전히 가져간다. 하지만 OS 에서 바라보는 logically two way 또는 four way로 구성된다. 단, power7에서 simultaneous multithreading 이 enable되어 있어야 한다.

이것은 partition type에 독립적이다. shared partition 을 한개의 virtual processor로 구성하면 logically tow or four way로 구성한다.

 

When to Use Simultaneous Multithreading

SMT가 효과적인것:

– two or four thread 가 동일 resource에 대해 경쟁해선 안된다.

–전체적인 throughput이  하나의 thread 처리에 대한 속도 보다 중요한 경우

cache miss로 인한 waiting time 이 많을 경우  : data가 cache에 load되는동안의 waiting

-Workload 가 충분해서  모든 available logical processor 가  advantage를 가져갈 수 있는 상황 (?) ; 이해 안됨. : mpstat -s 또는 sar -P All 명령으로 distribution을 모니터링 할 수 있다.

 

SMT가 비효율 적인 것.

– 한개의 thread가 느리고, 이게 동일 processor에서 도는 다른 thread

– thread가 동일한 실행 pattern을 가졌거나, 지속적으로 동일한 실행 unit에 있는 thread와 compete하는 경ㅇ우

-workload를 활용 할 충분한 thread가 없는 경우. (내생각), workload 에 충분한 thread가 없을 경우,, 말하자면 logical processor 가 증가하는데도 이를 사용할 thread가 없을 경우 이는 비효율 적이다. 

 

Thread mode는 1-way,2-way, 4-way 로 동적으로 변경 가능하다. : smtctl  명령 이용해서 변경 가능

 

SMT는 위에서 언급했듯이 일상적인 throughput이 좋아야 할때 적합하다. 특정 thread에 대한 성능이 우수해야 하는경우에는 좋지 않다.

web server 나 database server같은것이 적합한 case이다. 

Workload가 높은 CPI(Cycles Per Instruction)count를 갖고 processor 와 memory resource utilize가 부족하다면 보통 최고의 simultaneous multithreading 효과를 볼 수 있다.

 

SMT가 항상 좋은것 아니다. workload가 하나의 소프트웨어에서 아주 크게 오는 경우라면…이건 smt가 좋지 않다.

 

SMT Thread Sensitive Scheduling  => 다시 여기 부터…

Thread 의 실행이 SMT모드에서 single thread모드보다 느릴때

aix 는 thread -sensitive scheduling과 hypervison interaction 을 조합해서 performance optimize를 한다.

work를 load한다. primary thread 에, 이게 secondary thread로 옮겨가기 전에..

Hardware thread priority is used by the processor core to decide the rate at which to dispatch instructions for each logical processor
–    ->This priority is reduced when a thread is doing unproductive kernel work (i.e. lock spins)
–    -> This priority is boosted when a thread is holding a contended kernel lock

thread 가 idle loop에 들어가면 logical processor 는 휴면 상태에 들어간다.

    -> 휴면 상태에 들어간 것을 snoozing이라 한다.

    ->이때 aix는 h_cede hypervisor call을 한다. 이 call에 의해 snoozing mode로 들어가는 것임

     ->schedo parameter 중에 smt_snooze_delay 는  thread가 cede call이 발생하기 전  idel loop에 들어가 는 시간을 명시한다.

 

 

active thread를 dormanat state로 보내는것을 snoozing이라 한다.

dedicated processor partition에서 만약에 수행할 만한 충분한 task가 없을때 os의 idle process 인 wait kproc 에 리소스가 할당 될거다.

이건 os  idle process thread를 snooze하고 single thread mode로 전환 하는데 좋다.

모든 processor resource 는 처리할 work가 생기면 모두 enable될거다.

thread를 snooze하는 것 은 Aix가 h_cede hypervisor call 을 호출함으로써 수행된다. 

snooz상태의 thread는external interrupt  가 있거나 h_prod hypervisor call이 발생하면 wakeup한다.

다른 task가 실행준비가 되면 processor 는 single thread mode에서 SMT 모드로 바뀐다.

idle 상태가 발생하자 마자 thread를 snooze상태로 바꾸는것은 효과적이지 않다.

snooze가 발생할때  실행준비가 된 다른 thread  가 run queue 에 있다면 결과적으로 thread가 start up을 해야하는 latency가 발생하므로 비 효율 적이다.

만약 os가  thread를 snoozing 하기 전에..work가 생기기를 잠깐동안  기다린다면  이건 performance에 좋을 거다.

이 잠깐의 idle spinning time이 바로 SMT snooze delay이다.

 

정리하면 실행할 업무가 없으면 snooze상태가 되는데 이게 업무가 없다고 바로 snooze상태로 가는게 아니라 snooze delay 시간 만큼 대기 후 snooze 된다는 것다.

snooze했다고 다시 wake up하는데도 시간이 걸리기 때문에 이 사이에 업무가 발생하면 오히려 snooze하는게 performance에 안좋은 영향을 준다는 것이다.

 

 

Processor Affinity and Binding

-processor affinity 라는건 processor에서 바로 이전에 A 라는 thread를 실행했다면 A thread가 올라 왔을때 우선 해당 processor에 먼저 dispatching한다는 거다.

-AIX에의해서  processor affinity 수행된다.

–만약에 thread가 interrup되고, 나중에 다시 동일 processor에  dispath 된다면 cache에는 아직 해당 thread에 대한 정보가 남아 있을거고 이게 cache에 다시 load하는 단계를 없애니 더 효율 적이다.

-bindprocessor 명령어는 bindprocessor() 서브루틴에 의해 수행된다. 이건 특정 process의 thread를 특정 processor에 binding할 수 있다. 의도적으로 하는 만큼 performance에 효과적일 수 있지만 잘 못 사용하면 더 나쁜 performance를 만들 수도 있다.

 

note– 위 내용과 동일 반복

Viewing Processor Statistics with topas/nmon

topas command는 local system의 resource사용에 관한 report를 보여준다.

processor utilization은 PURR-base register 공식으로로 계산된다.  SMT 나 shared processor모드 일때

 

 

Unit 2. Process Management Framework

본 unit에서는 process management framework에 대해서 설명한다. 

aix kernel이 processes 와 thread를 관리하기 위해 사용하는 framework이다.

이 framework는  aix kernel code가 도는 environment라면 모두 지원한다.

 

이 챕터에서는 aix kernel구조를 배우고, aix의 실행환경과 kernel이 manage를 위해 사용하는 preocesses와 thread의  data structure 에 대해 배운다.

 

AIX Anatomy

ㅇ

aix os의 기본 목적은 application이 실행 될 수 있는 환경을 제공해주는데 있다. os는 대표적으로 hardware resource를 관리한다. ( memory, CPU , I/O 등)

kernel은 os의 base program이다. 이게 바로 hardware와 application 사이에서 중개자로서 act 한다.

kernel은 system call이라는 interface를 제공하여 program으로 하여금 hardware 요청을 할 수 있게ㅅ한다.  kernel은 이런 요청들의 우선순위를 관리한다. 

전통적으로 , os의 kernel은 모든 hardware를 관리한다. os가 logical partition에서 돌아갈때 aix kernel 은 POWER Hypervisor와 interact 하여 hardware관리를 한다. aix 7 kernel은 lpar위에서 돌게 구성되어 있다. 단 하나의 lpar 일지라도 무조건 lpar위에 os가 올라가는 구성이다. 고로 hypervisor를 통해야만 hardware에 접근이 된다.

 

Kernel Components

위 이미지에서 보는바와 같이 kernel은 몇개의 component로 이루어져 있다. 이 component들은 각각의 부분들이 application에게 적덩한 service를 제공한다. 

aix 7 kernel image는 /usr/lib/boot/unix_64 경로에 있다. 이 경로는 symbolic link 로 되어 있어 /unix로 접근해도 된다.

 

Kernel Extensions

aix kernel은 동적으로 확장된다. 추가된 routine으로 kernel extension이라 부른다.

kernel extension은 동적 loadable module 이라 설명 할 수 있는데 이는 kenel에 functionality를 추가한다. 이 모듈은 kernel의 protection domain 내에서 동착한다. user level code는 system call interface를 통해서만 kernel extention에 접근 할 수 있따.

kernel extenstion은 extensibility, configurability , 시스템관리의 편의성 등을 추가한다.

aix 7은 64bit kernel extension만을 지원한다.

 

Mode and Environment

위 이미지는 lpar환경에서 kernel과 hypervisor의 역활을 보여준다.

process는 usermode에서 system call 을 통해 kernel에 요청을 하고 ,  system call이 만들어 지면  user mode에서 kernel mode로 mode swithc가 수행되고, user에 의해 요청된 작업이 수행된다. (그전에 security check가 이루어진다.) ,kernel은 꼭 hypervisor call을 요청한다. hardware resource를 써야 하기 때문에. ( non lpar system에서는 hypervisor call이란게 없다.)

hypervisor call은 kenel에 의해서만 만들어 질 수 있다.

 

Process Management Header Files

header file은 C 언어로 작성되어 있다.

header file은 subroutine을 정의한다.

header file은 typedef data type을 한다.(data type을 정의)

header file은 System parameter 와 특성을 구성

header file은 정수 와 macro 등을 재 정의할 수 있다. 기본 C 언어에서 제공해주는 것 대신..

aix heder file

system header file은 /usr/include에 위치하고 있다. 아래와 같은 구조로 이루어져 있다.

 

Conditional Compile Variables

code compiling시에 개발자가 컴파일관련 변수를 정의 하게 된다. header file을 참고하여.

가장 주용한 컴파일 변수는 아래와 같다.

 

kernel code를 개발자가 컴파일 할때 가장 중요한 것중 하나가 컴파일 값들을 저으이 하는 거다.

특히 특정 컴파일 값들에 의해 kerner type이 지정되므로 꼭 defined 되어야 한다.

aix7에서 header file 은 64bit kernel을 쓰도록 설정 된다. 

 

Directives in Header Files (1 of 2)

__64BIT_KERNEL  값이 정의되지 않으면 sigset_t 가 정의되고 이 코드는 64bit kernel용으로 사용된다. 

=>잘 이해가 안되는데 언뜻 봐서는 sigset64_t가 마치 64bit을 정의 하는것 같은데 반대이네… 가볍게 찾아본 바에 따르면 sigset이란것이 block 또는 무시를 위한 code이기 때문인듯 하다. sigset64_t라고 하면 64를 무시 하라라는 의미 정도로 받아 들이면 되지 않을까?

위 이미지는 /usr/include/sys/proc.h 파일을 보여준다. 이 header file은 kernel에서 processes의 정보를 hold하기 위해 사용되는  구조체 의 definition을 포함 한다. 

aix7부터는 위 code가 사용되지 않는다. 32bit support를 하지 않는다.

위 이미지는 /usr/include/sys/thread.h 파일이다.

해당 파일은 kernel이thread정보를 담기위한 구조체 정의를 포함한다.  

__64BIT_KERNEL  이 not define 이면 uint t_ulock; 가 사용된다는 거다. aix7에서는 이 코드가 사용되지 않는다. 32bit를 지원하지 않기 때문에…

aix 7에서는 log t_ulock만 사용되는 거다.

 

User Process

user process라 하는것은 program이나  command 가 수행될때 생성된다.

process는 는 thread가 수행될 environment를 제공한다.(최소 한개 이상의 thread를 포함한다.)

process는 resource 를 할당 받아서 자신의 thread들에게 공유한다.

process가 새로 생성되면 이 process는 resource owner 가 된다. resource는 thread가 요청하는 것이다.

user process에 포함되는 resource는 address space, set of open file pointer, user credential등이 있다.

 

Threads of User Processes

디스패치가 가능한 개체로서 single flow 로 control 된다.

resource를 같은 process의 다른 thread와 share한다.

최소한의 resource를 필요로 한다. process가 생성될때.

initial thread는 process가 생성될때 같이 생성된다. – 다른 thread는 process의 필요에 따라 생성된다.

thread는 process의 가이드에 의해 실행되는 path 라고 생각하면 쉽다.

각각의 thread는 고유의 context를 갖고 있다. (stack, CPU register value) , thread가 running할때 cpu에 load된다.

=>그림에서 보면 process는 user mode에 있고 , thread는 kernel모드에 있다. user thread여도 kernel모드에 있는게 맞나?? 아래 이미지를 보면 답이 나온다.

 

User Threads and Kernel Threads of User Processes

user thread를 pthread라고 부른다.( POSIX thread)

– user level의 thread library에 의해 created and managed 된다.

– kernel은 user thread의 존재에 대해 모른다.

– user threads는 실행되기 위해서는 꼭 kernel thread와 mapping되어야 한다.

user process의 kernel thread 

– kernel managed thread라고도 불린다.

-kernel thread table에 올라간다.

– user mode 또는 kernel mode에서 수행 된다.

 

kernel thread는 kernel thread table에 올라가고 , 이를 통해 system에 dispatch된다. kernel thread는 run queue에 올라 갈 것이고  processor가 수행을 위해  이를 선택 할 것이다.

 

user process의 kernel thread는 일반적으로 대부분의 시간을 user mode에서 보낸다. 하지만 system call (kernel mode로 switch함)을 통해  kernel code를 수행 할 수 있다. 

주의할건 thread는 임으적으로 kernel에 있는 function을 수행 할 순 없다. 무조건 system call을 통해서만 kernel function을 이용 할 수 있다.

 

 

Thread Scope Models

user thread는 thread libray를 통해 kernel thread에 mapping된다.

3가지 모델에 의해 POSIX thread 가 kernel thread에 mapping될 수 있다. 

1) 1:1 model(system scope)

2) M:1 model(process scope)

3) M:N model

Thread Execution of User Processes

 

application이 run할때 , thread에 의해 수행 가능한 3가지 source code가 있다.

3가지 를 이해해야만 cpu 사용량 분석이 가능해진다. 매우 중요하다.

 

cpu cycle 은 application에 의해 사용되는데 , 이는 application code, shared libray call, system call 이 수행될때 에  사용된다.

 

cpu cycle이 application code와 shared library routine에 있을때는 %user category로 잡히고, system call을 수행할때는 %sys category로 잡힌다.

 

Kernel Processes and Kernel Threads of Kernel Processes

kernel process

-kproc 으로 알려져 있다.

-krenel domain 내에서 생성

-shared libray code를 사용하지 않는다.

-poll 되어야 한다. (선택할 것과 무시할것 분류)

– 한개 initial thread에 의해 생성된다.

kernel thread of kernel process:

-kernel – only thread로 알려졌다.

-kenel mode에서만 수행된다.

 

Kernel threads of kernel processes

system에 있는 process를 kernel process라고 한다. kernel process는  kernel mode에 의해 생성되는 special category이다.

kernel process의 kernel thread는 kernel-only thread로 불린다.

kernel-only thread는 kernel모드에서만 실행된다. 

kernel thread of kernel process는  kenel threads of user process와 비슷하게 kernel thread table에 명명 된다.

kernel process는 text 와 data를 kernel과 공유한다. 하지만 고유의 u-area 와 kernel stack영역을 갖는다.

kernel process 는 shared library code, user protection domain code를 사용할 수 없고  signal에 대해 poll 된다.

=>  poll한다는 개념은 내가 나를 사용할 애들에게 나 쓸래? 라고 signal을 날리고 응답이 없으면 다른 애에게 다시 묻는 형태의 작업을 말한다.

 

Kernel Only Thread Execution

kernel process의 address space는 kernel protection domain 영역이다.

process address space에 user space는 없다.  kernel process의 thread는 kernel -only thread이다.

CPU cycle 은 kernel thread에 의해 사용되고 %sys category로 분류된다.

 

=>이쯤에서 kernel thread, user thread , kernel only thread에 대해 정리 한번 하고 가자.

 

 

 

 

Interrupt Handlers

Aix의 notifying mechnism 중 external event 가 갖는 영역 

현재 수행중인 thread를 interrupt한다.

   – 수행중인 thread 의 context(register정보 같은것) 를 저장한다.

   –  다시 interrup됬던 thread가 dispath되면 context는 복구 된다.

performance impacts

   – cache에 있던 contents(TLB , data cache ) 는 reconstruct된다.

   – interrup handler 와 intrrupt된 thared 모두 cache- miss나 TLB -miss 로 인해 delay가 생길 수 있다.

 

external event에 대한 aix의 notifying mechanism 은  interrrupt에 대한 특정 영역을 차지하고, 현재 운영중인 thread에 대한 context 를 interrupt handler로 넘겨준다.

interrupt handler가 실행되기 전에, 충분한 hardware state가 필요하다. 현재 수행중인 thread의 context를 저장하고 interrup handdling이 끝나면 context가 복구되어야 한다. 

새로 invoke된 interrrupt handler는 hardware의 상위 계층으로 올라가며  page fault를 제외한 모든 종류의 delay를 경험한다.

interrupt handler 가 매우 최근에 수행 되었거나 매우 경제적인 타이밍에 interrupt한 경우가 아닌경우 외에는 아쉽게도 그것과 관련되 code와 data는 모두 TLB와 cache 영역에 있게 된다.

 

interrupt되었던 thread가 다시 dispatch되면 , context 가 발생하고 register contents등이 restore된다. 이를 통해 thread의 기능이 정상화 된다.

어쨌든 TLB 와 cache 에 있는 contents는 reconstruct 되어진다.  이는 기본적으로 program의 추가적인 요청에 의해 수행된다. interrupt handler와 interrupt된 thread는 inttrrup의 결과로 cache-miss와 TLB-miss에 따른 delay를 격게 된다.

 

TLB 란 Translation Lookaside Buffer 로서 CPU cache라고 생각하면 된다. 프로그램이 수행되기 위해 사용하는 page table은 main memory에 올라간다. (page란 memory를 사용하는 단위 정도로 생각하자) 그러므로 program에 의한 memory 접근은  두번 필요한거다. 예를들어 A라는 data를 얻어야 하면 일단 main memory에 접근하여 A라는 data가 있는 page 주소를 알아내고 다시 그 주소를 바탕으로 메인 메모리에 접근하여 A라는 데이터를 가져오게 되는거다. 이 얼마나 비 효율 적인가..

자주 사용되는 page에 대한 주소정보를 TLB라는곳에 올려둬 memory에 가는 만큼 시간을 아끼는 것이다. tlb는 cpu에 있고 그만큼 빠르다.

 

Interrupt Handler Levels

First level interrupt handler (FLIH)

– processor가 interrupt를 받음 수행된다.

-FLIH는 context 정보를 저장하는 역활을 하고  SLIH를 invoke한다.

 

Second level interrupt handler (SLIH)

–  FLIH에 의해 invoke되고, device driver의 일부 이다. 

-interrupt processing을 완료하는 역할을 함

 

Interrupt Processing

hardware interrupt는 임시 context switch를 만든다. 각 interrupt 수행 시간동안, 수행중인 context 는 저장되어야 interrupt가 끝나고 이어서 수행 될 수 있다.

 

interrupt는 CPU가 현재 수행하는 process를 interrupt한다. 결과적으로, 다수의 mstsave area가 필요하다. 각 interrupt에 대한 context를 저장하기 위해, 

aix는 각 상황에 대한 mstsave area pool을 유지하고 필요할때 사용한다. 

이게 필요한 이유는 interrupt가 thread와 달리 transient entity (실체가 없는 개체) 이고 고유의 mstsave 구조를 갖지 않기 때문이다.

. 각 processor는 mstsave area에 대한 point를 갖고 interrupt가 발생하면 이를 사용하낟. 이 pointer는 current save area(CSA)라 불린다.

 

AIX가 interrupt를 받으면 가장 높은 우선순위로 수행된다. 현재 수행되던 process 는 context를 mstsave area에 저장하게된다. 기존에 저장된게 있더라도 새로운 mstsave에 저장하고 이를 통해 history관리가 된다.

 

 

User Process Creation (1 of 2)

ㅇ

ㅇ

ㅇ

ㅇ

ㅇ

ㅇ

ㅇ

ㅇ

 

—————————————————————————————————————————————–

granularity – 입자,알갱이 라는의미 computer 에선, 단위화, 로 해석할 수 있다. 

                     여러 function을 잘개 쪼개서 지원하고 이를 조합하여 또다른 기능을 해내고.. 이런 의미