요약

  • 수신 라이브락은 도착 인터럽트가 프로세서를 독점해 프로토콜 처리, 전송, 응용 프로그램의 완결을 막을 때 나타나며, 유용한 처리량은 0으로 떨어질 수 있습니다.
  • Mogul과 Ramakrishnan은 깨우기 인터럽트, 라운드로빈 폴링, 콜백별 쿼터, 조기 폐기, 큐 상태 피드백, 사이클 한도를 결합했습니다. 쿼터 없는 폴링은 여전히 실패했습니다.
  • 측정은 10 Mbit/s Ethernet에 연결된 느린 단일 프로세서 DECstation에서 이루어졌습니다. 5~10패킷 쿼터와 큐 임계값은 보편적인 튜닝 값이 아니었습니다.

활동은 많지만 완성되는 일은 없음

인터럽트는 하드웨어 이벤트에게 평범한 작업을 제치고 앞설 권리를 줍니다. 도착이 드물 때 이 권리는 지연을 줄입니다. 처리 용량을 넘어서면, 모든 진행을 없앨 수도 있습니다.

Mogul과 Ramakrishnan이 연구한 4.2BSD에서 유래한 모델에서, 드라이버는 높은 우선순위 수준에서 인터페이스로부터 패킷을 뽑아 IP 큐에 넣었습니다. 프로토콜 처리는 나중에 더 낮은 우선순위에서 이루어졌습니다. 따라서 새 도착은 언제든 큐를 비우는 단계를 중단시킬 수 있었습니다. 큐가 차기만 하면, 커널은 결국 배달 전에 버려질 패킷들에 계속 사이클을 투자했습니다.

이것은 영구적 정지가 아니었습니다. 트래픽이 줄면 시스템은 다시 생산적으로 돌아갔습니다. 반면 과부하 동안 프로세서는 패킷도 전송하지 않고 응용 프로그램도 먹여주지 않은 채 최대 속도로 돌아갔습니다. 그러므로 올바른 분모는 처리된 인터럽트 수가 아니라 최종 소비자에게 도달한 패킷 수였습니다.

인터럽트 우선순위가 숨은 스케줄러 역할을 했다

일반 스케줄러는 이 작업에 거의 손을 댈 수 없었습니다. 그보다 먼저 고정된 우선순위 계층이 결정했습니다. 이 계층은 패킷 입수는 우대하고 서비스를 완성하는 단계들, 즉 프로토콜, 전송, 라우팅 유지, 로컬 관리, 사용자 프로세스를 굶겼습니다.

인터럽트 결합은 단위당 비용을 줄이고 한계점을 미뤘지만 구조는 고치지 못했습니다. 더 효율적인 입구도 결국 입구일 뿐이었고, 출구나 공정성을 보장하지 않았습니다.

인터럽트는 감지하고, 폴링은 나눈다

수정된 커널은 부하가 낮을 때는 인터럽트를 그대로 유지했습니다. 부하가 높아지면 핸들러는 장치가 주의를 필요로 한다는 사실만 표시하고, 폴링 스레드를 시작하고, 그 인터페이스의 인터럽트는 마스크된 채 두었습니다.

이 스레드는 수신·전송 이벤트 소스를 라운드로빈으로 순회했습니다. 각 콜백에는 패킷 쿼터가 주어졌습니다. 대기 중인 작업이 사라지면 인터럽트를 다시 활성화했습니다. 인터페이스에서 받아들인 패킷은 새 우선순위 큐에 다시 넣는 대신 목적지까지 가능한 한 멀리 밀어넣었습니다.

인터럽트 대 폴링이라는 대립보다 이 조합이 더 중요했습니다. 인터럽트는 예측 불가능한 이벤트를 빠르게 감지했습니다. 폴링은 이미 기계를 포화시켜 예측 가능해진 흐름을 분배했습니다.

쿼터 없는 실패

가장 유익한 결과는 부정적인 것이었습니다. 쿼터가 없으면 수신 콜백은 언제나 다음 패킷을 발견하고 결코 손을 놓지 않았습니다. 폴링 루프는 전송 완료에 도달하지 못했습니다. 출력 디스크립터는 차 있었고 전송 큐는 채워졌으며 유용한 처리량은 거의 0으로 떨어졌습니다.

폴링은 독점을 없애는 대신 옮겼을 뿐이었습니다. 이 기계에서는 한 번의 턴에 5~10패킷이 안정적이고 거의 최적에 가까운 동작을 만들었습니다. 더 큰 배치는 전환 비용을 줄이지만 지연을 늘리고 다른 작업을 굶길 위험을 키웠습니다. 저자들은 다른 프로세서나 다른 인터페이스라면 다른 튜닝이 필요하다고 명시했습니다.

일찍 버리고 하류를 들어라

과부하 상태에서 일부 패킷은 끝까지 진행될 수 없습니다. 인터페이스에서 버리면 드라이버, 프로토콜, 큐잉 비용이 사실상 버려진 단위에 낭비되는 것을 막습니다. 그러나 조기 폐기는 입력이 하류가 더 이상 진행하지 않음을 알 때만 유용합니다.

screend를 사용한 실험에서 커널은 큐가 75%에 이르면 입력을 중단하고 25%에서 재개하며, 약 1밀리초의 지연을 안전밸브로 사용했습니다. 이 값들은 임의로 정해졌습니다. 오래 남은 결과는 증명 루프였습니다. 하류 큐가 가득 차면 입수를 멈춰야 하며, 단순히 늦은 손실을 더 기록하는 것으로는 부족했습니다.

또 다른 메커니즘은 10밀리초 창 동안 네트워크가 소비한 사이클을 셌습니다. 허용 몫이 소진되면 입력이 멈춰 사용자 프로세스와 시스템 유지가 진행할 수 있게 했습니다. 로컬 콘솔은 다시 반응하게 되었지만, 원격 교류는 손실로 계속 타격을 입었습니다. CPU를 비축한다고 과부하가 용량으로 바뀌지는 않았습니다.

분모를 갖춘 측정

라우터는 Digital UNIX V3.2를 탑재한 DECstation 3000/300으로, 당시 가용 Alpha 중 일부러 가장 느린 것을 골랐습니다. 10 Mbit/s Ethernet 두 개를 잇는 라우터였습니다. 각 시험은 4바이트 페이로드를 가진 UDP 데이터그램 10,000개를 보냈고, 완전히 규칙적이지 않은 속도는 여러 초에 걸쳐 계산했습니다.

원래 커널과screend를 함께 쓰면 성능 저하는 초당 약 2,000패킷 위에서 시작되었고, 완전한 라이브락은 6,000 근처에서 나타났습니다.screend가 없으면 처리량은 초당 약 4,700패킷에서 정점을 찍었습니다. 이 보고서는 이 수치를 더 빠른 네트워크와 프로세서에 그대로 확장하는 것을 금했습니다. 진짜 SMP는 시험되지 않았고, 그 정책은 언제 포기할지를 알려줄 뿐 어떤 패킷을 살려야 하는지는 알려주지 않았습니다.

Linux의 현재 NAPI 문서는 여전히 익숙한 형태를 설명합니다. 인터럽트가 폴링을 계획하고, 처리 동안 IRQ는 마스크되며, 예산이 턴을 한정합니다. 이것은 운영상의 비교이며, 모든 현대적 과부하가 같은 병리일 것이라는 증명이 아닙니다.

Google Research의 Mogul 프로필은 그가 DEC/Compaq WRL, HP Labs, Google의 네트워크 인프라를 거친 경력을 담고 있습니다. 이 역사적 논문은 Ramakrishnan과의 공동 작업으로 남아 있습니다. 가장 단단한 교훈은 거절된 카운터에 있습니다. 매우 바쁜 기계는 출력에 도달하지 못하는 것을 “처리량”이라 부를 수 없습니다.

출처