비선점형 SMP 커널에서 CPU 별 성능에 대한 질문이 있습니다.
현재 개발중인 장비에 두개의 CPU 가 있습니다. (각 물리 코어 6개, 하이퍼스레딩으로 12개, 총 24개 코어 사용)
VPN 용 커널 모듈을 개발 중인데 AES 암호화를 위해 Intel 의 AES-NI Instruction 을 적용하여 개발하였습니다.
커널은 2.6.24.7, 비선점형 SMP 로 빌드된 커널 입니다.
AES-NI 는 xmm 레지스터를 사용하기에 kernel_fpu_begin() 과 kernel_fpu_end() 로 감싸고 있습니다.
이렇게 개발된 상태에서 동작은 정상적으로 하고 있습니다.
CPU Affinity 를 조정하여 두 CPU (총 24개의 코어) 에 로드가 적절히 분배되는 것도 확인했습니다.
그런데 실질적으로 성능을 측정해보면 모든 동작을 Affinity 설정을 통해 CPU 0번에 몰았을 때 더 좋은 성능을 보입니다.
그리고 CPU 1번에 몰았을 때에는 CPU 0번에 몰았을 때보다 성능이 현격히 떨어집니다.
하드웨어 상으로 두개의 CPU 는 동일합니다. 혹시나 해서 CPU 를 바꿔껴서 테스트해봤지만,
CPU 0 번에 비해 CPU 1 번의 성능이 떨어집니다.
질문을 정리해보자면,
1. 2.6.24.7, 비선점형 SMP 커널에서 커널 모듈 개발 중
2. Intel 의 AES-NI instruction 이용
3. CPU 0, CPU 1 을 모두 사용했을 때 성능이 CPU 0 에 몰았을 때보다 좋지 않음.
4. CPU 0 만 사용했을 경우와 CPU 1 만 사용했을 경우에도 성능에 큰 차이를 보임. (CPU 1 의 성능이 현격히 떨어짐)
SMP 환경에서의 개발이 처음이라 그런지, 제 상식으로는 잘 이해가 되질 않습니다.
작은 힌트라도 떠오르시는 부분이 있으면 공유해주세요.
어디를 어떻게 확인해봐야될 지 난감하네요.
감사합니다.
캐쉬의 영향은.....
구체적인 설계 방식과 테스트 환경이 정확히 기술 되어 있지 않아서 추측으로만 답변을 합니다.
테스트를 위한 입력 데이터가 네트웍 패킷 이라면,
패킷이 도착 되어 처리되는 CPU와 암호화를 하는 CPU가 다르다면 캐쉬 미스가 발생 합니다.
그래서 캐쉬 미스에 대한 깊은 고려가 필요 합니다.
또한 암호화 함수를 수행하는 동안 CPU가 블럭 되어 있다면, 성능 향상에 미미 할수도 습니다.
블럭 된 시간에 무엇인가(다른 패킷의 수신이라던가, 송신 이라던가...)을 할 수 있도록 설계 되어야 합니다.
입력 데이터가 패킷이 아니라면,
데이터 입력 시간에 대한 다른 저해 요인을 모두 제거해야 할듯 합니다.
그런데 동일한 기능이 정말 동시에 두개의 CPU에서 실행 되는 것이 확인 되었나요?
lock이라던가 기타 irq handler 등의 제약 사항에 대해서도 검토가 되었나요?
제 조언은 여기까지 입니다.
하나의 CPU 만 사용하는 경우의 성능 차이
조언 진심으로 감사 드립니다.
두개의 CPU 를 모두 사용하는 경우라면 말씀하신 것 처럼 캐쉬 미스, 블락, lock 등에 대해서
면밀히 검토를 해봐야겠습니다만...
CPU Affinity 를 조정해서 들어오고 나가는 패킷의 처리를 모두 하나의 코어로만 몰았을 때
CPU 0 에 있는 코어와 CPU 1 에 있는 코어가 큰 성능 차이 (대략 3:2 정도) 를 보이는 것은
어떤 이유가 있을까요? (두개의 CPU 를 동시에 이용하지 않는 상황)
어떠한 추측이라도 좋으니 생각 나시는 것 있으시면..던져 주시면 감사하겠습니다.
캐쉬 영향
저도 irongate님께서 추측하신 것 처럼 캐쉬 영향 때문이라는 것에 한표 던집니다.
CPU Affinity를 조정하셔서 패킷 처리를 하나의 코어에 몰았다고 하셨는데,
네트워크 드라이버, TCP/IP 스택 모든 레이어에서 같은 코어에서 실행되고 있는지
확인 하셨는지요?
CPU 1 Affinity를 하였을 때 드라이버에서 패킷을 받아오는 것은 CPU 0 캐시에 캐싱
되고 TCP/IP 스택 처리 및 프로세스 실행이 CPU 1에서 되는건 아닌가 추측 해
봅니다.
Just do it!
캐쉬 영향이 어느 정도일까요..
댓글 진심으로 감사드립니다.
네트워크 드라이버, TCP/IP 스택 등이 어떤 코어에서 실행되고 있는지는
확인해보지 못했습니다만..
sar 를 통해 코어별 사용량을 확인해본 바로는 제가 사용을 의도한 코어에서
모든 처리가 이루어지고 있지 않나 추측해봅니다.
예를 들어 0번 코어를 사용하려고 한다면 패킷이 들어오고 나가는 인터페이스쪽의
rx 큐를 모두 0번 코어로 설정을 하는 방식으로 테스트했습니다.
tx 큐의 Affinity 는 모든 코어에 골고루 분배되어 있는데...
VPN 에서 암호화/복호화, Hash 가 차지하는 비용이 거의 대부분이라 여겨 rx 큐에만 Affinity 를
설정했습니다. (테스트해본 바로도 tx 큐쪽의 Affinity 설정은 별 영향을 미치지 않았습니다.)
제가 초짜라..캐쉬 미스에 대한 비용이 어느 정도일지 추측이 잘 안됩니다.
CPU 0 쪽 코어로만 패킷을 몰았을 때는 캐쉬 미스가 거의 나지 않는다,
CPU 1 쪽 코어로만 패킷을 몰았을 때 많은 캐쉬 미스가 난다 라고 가정했을때
성능 차이가 어느 정도 날까요..
현재 CPU 0 쪽 코어로만 몰았을 때 네트워크 Throughput 이 600 Mbps 라고 하면,
CPU 1 쪽 코어로만 몰았을 경우는 400 Mbps 에도 못미치는 성능을 보이고 있습니다.
p.s 역시 답변다운 답변을 해주시는 분들은 KLDP 에밖에 없네요..
최근에 만들어진 인텔 cpu에서는 코어별
최근에 만들어진 인텔 cpu에서는 코어별 asymmetric한 성능을 보이는데요,
- turbo boost
- dynamic power management?
를 구글에서 찾아보세요.
tx의 영향을 제거해보심이....
우선 암호화 과정이 끝나는 곳에서 패킷 카운트하는 기능을 넣고, 이 값을 조회 할 수 도록 한 다음...
암호화 처리가 끝난 모든 패킷을 drop 해서.... Tx에 대한 영향을 완전히 제거한 다음 테스트를 해보세요.
Tx 비용이 암/복호화 비용이 비해서 작다고는 해도 성능 저하의 원인을 찾는데 도움이 됩니다.
그리고 캐쉬 미스에 의한 성능 저하는 최악의 경우 6:4 보다 더 낮게 나올수도 있습니다.
아... tsgates님의 지적대로, dynamic power management에 의해서 CPU 동작 클럭이 변경 될수 있습니다.
저도 이 기능 때문에 상당히 삽질을 한 기억이 있습니다.
부팅이 완료된 상태에서 CPU 동작 클럭을 조회해서 동일한지도 확인해 보세요.
아마, BIOS에서 on/off 할 수 있던듯 합니다.
캐쉬 미스의 영향이 크게 나올 수 있군요.
캐쉬 미스로 인한 성능 저하가 6:4 보다 더 낮게 나올 수도 있다니..
제가 너무 캐쉬 미스를 우숩게 보고 있었군요..
일단은 조언해 주신데로 캐쉬 미스쪽을 살펴 봐야겠네요.
oprofile 을 돌려보면 되겠죠..?
부팅이 완료된 상태에서 cpuinfo 를 봤을 때 모든 코어의 bogomips 가 거의
동일하게 나오는 것으로 봐서 CPU 동작 클럭이 변경된 건 아니지 않나 추측해봅니다.
캐쉬 미스도 원인이 아니라면.....또 뭘 의심해볼 수 있을까요....?
조언 감사합니다.
asymmetric하게 동작한다는것은, 한쪽 코어가
asymmetric하게 동작한다는것은, 한쪽 코어가 다른쪽 코어에 파워를 끌어주어서 133MHz*step으로 boosting시킬 수 이다는 이야기인데요. 한 다이 (코어들)에 들어가는 파워를 한 컨트롤러가 관리하는데, 파워가 절달될 수 있는 코어는 core0 뿐이죠. 지금하고 있는 일들의 로드를 생각해보면 케시는 들어나게 영향을 주지 않는걸로 보이고. cpu/core0과 cpu/core1을 affinity말고 boot parameter나 sysfs로 끄신후에 테니스트 해보길 바라네요. (affinity로 세팅을 잘했다고 생각되면 추측하시는 캐쉬의 영향은 커널쪽에서의 영향뿐이거든요.)
네할램이나 샌드비릿지에서 흔히 보이는 현상입니다. cpuinfo에서 보신것은 cpu에서 리보트하는 클럭이고, 실제 동작하는 클럭은 다르죠. 그리고 캐쉬미스가 영향일것 같다는 추측이 들면 oprofile로 쉽게 프로파일해 볼 수 있습니다.
댓글 달기