Windows Administration

Windows Vista 커널 속으로: 1부

Mark Russinovich

 

한 눈에 보기:

  • 스레드 우선 순위 및 사용 계획
  • 파일 기반 심볼 링크
  • I/O 작업 취소

이 기사는 Windows Vista 커널의 새로운 기능을 다루는 연재 기사의 첫 회입니다. 이번 호에서는 프로세스 및 스레드 영역과 I/O의 변경 내용을 살펴보고 다음 호에서는 메모리 관리, 시작 및 종료, 안정성 및 복구, 보안 등을 다루겠습니다.

이 기사에서는 Windows Vista™ 커널, 특히 Ntoskrnl.exe 및 이와 밀접하게 연결된 구성 요소의 변경 내용만을 다룹니다. Windows Vista에는 이 기사에서 다루는 커널에 해당하지는 않지만 다른 중요한 변경 사항도 많이 있다는 점에 유념하십시오. 이러한 변경 사항으로는 향상된 셸(예: 통합 데스크톱 검색), 네트워킹(예: 새로운 IPv6 스택 및 양방향 방화벽), 차세대 그래픽 모델(예: Aero™ 투명 효과, Windows® 프레젠테이션 파운데이션, 데스크톱 창 관리자, 새 그래픽 드라이버 모델) 등이 있습니다. 이 기사에서는 또한 Windows UMDF(사용자 모드 드라이버 프레임워크)와 KMDF(커널 모드 드라이버 프레임워크)도 다루지 않는데, 이것은 이전 버전의 Windows에서도 설치가 가능하기 때문입니다.

CPU 사이클 계산

Windows Vista는 보다 균형된 CPU 할당을 위한 CPU 사이클 카운터와 미디어 응용 프로그램이 오류 없이 재생되도록 하는 MMCSS(멀티미디어 클래스 스케줄러 서비스)를 비롯하여 프로세스 및 스레드 영역에서 다양한 향상된 기능을 제공합니다.

Windows Vista를 포함하여 모든 버전의 Windows NT®에서는 하드웨어 플랫폼에 따라 대략 10밀리초나 15밀리초마다 실행되도록 간격 타이머 인터럽트 루틴을 프로그래밍합니다. 루틴은 중단한 스레드를 파악하고 전체 간격 동안 해당 스레드가 실행된 것처럼 스레드의 CPU 사용 통계를 업데이트하지만 실제로는 간격이 끝나기 바로 전에 스레드가 실행되기 시작했을 수도 있습니다. 또한 기술적으로는 이 스레드에 CPU가 할당되었지만 하드웨어와 소프트웨어 인터럽트 루틴이 대신 실행되어 스레드는 실행되지 않은 경우도 있습니다.

스레드와 프로세스의 CPU 사용을 보고하는 진단 도구로 클록 기반 시간 계정을 사용해도 괜찮을 수 있지만 스레드 스케줄러가 이 계산 방법을 사용하면 불균형한 CPU 할당이 발생할 수 있습니다. 기본적으로 클라이언트 버전의 Windows 스레드에서는 최대 2개(포그라운드인 경우 6개)의 클록 틱을 실행할 수 있습니다. 그러나 스레드에는 시스템에서의 해당 동작과 기타 다른 작업에 따라 CPU 시간이 거의 할당되지 않거나 최대 6개의 틱(포그라운드인 경우 18개)이 할당될 수 있습니다.

그림 1에서는 우선 순위가 같은 2개의 스레드가 동시에 실행될 준비가 되었을 때 발생할 수 있는 불균형 상태를 보여 줍니다. 스레드 A가 다음 시간 조각 간격이 만료되는 시점까지 실행되면 스케줄러는 스레드 A가 전체 간격 내내 실행된 것으로 가정하고 스레드 A의 차례가 끝난 것으로 결정합니다. 게다가 스레드 A는 해당 차례에 발생한 인터럽트까지 실행 시간에 포함되는 불이익을 받게 됩니다. 다음 간격에서 스케줄러는 스레드 B를 선택하여 전체 간격 동안 실행합니다.

그림 1 불균형한 스레드 사용 계획

그림 1** 불균형한 스레드 사용 계획 **

Windows Vista의 스케줄러는 최신 프로세서의 사이클 카운터 레지스터를 사용하여 스레드가 실행하는 CPU 사이클 수를 정밀하게 추적합니다. 클록 간격에서 CPU가 실행할 수 있는 사이클 수를 예측하여 CPU에서 차례를 보다 정확하게 할당할 수 있습니다. 또한 Windows Vista 스케줄러는 인터럽트 실행이 스레드 차례에 불이익을 주지 않도록 합니다. 즉, Windows Vista에서는 항상 스레드가 CPU에서 최소한 자신의 차례를 갖고 실행을 위한 별도의 클록 간격을 갖지 않으므로 탁월한 균형성과 보다 명확한 응용 프로그램 동작을 구현할 수 있습니다. 그림 2에서는 Windows Vista가 두 스레드 모두에 적어도 실행을 위한 하나의 시간 조각을 제공하여 그림 1에 표시된 시나리오에 응답하는 방법을 보여 줍니다.

그림 2 Windows Vista 사이클 기반 사용 계획

그림 2** Windows Vista 사이클 기반 사용 계획 **

"프로세스 CPU 사용 관찰"에서는 Process Explorer 유틸리티를 사용하여 프로세스 CPU 사이클 사용을 직접 모니터링하는 방법을 보여 줍니다.

멀티미디어 클래스 스케줄러 서비스

사용자는 음악 및 비디오 플레이어를 포함한 멀티미디어 응용 프로그램이 원활한 재생 환경을 제공할 것으로 예상합니다. 그러나 바이러스 백신, 콘텐츠 인덱싱 또는 메일 클라이언트와 같이 동시에 실행되는 다른 응용 프로그램의 CPU 요구로 인해 원하지 않는 문제가 발생할 수 있습니다. 더 나은 재생 환경을 제공하기 위해 Windows Vista에서는 MMCSS를 채택하여 멀티미디어 스레드의 CPU 우선 순위를 관리합니다.

Windows Media® Player 11 등의 멀티미디어 응용 프로그램은 해당 멀티미디어의 특징을 나타내는 새로운 API(다음 레지스트리 키 아래에 이름별로 나열된 것 중 하나와 일치해야 함)를 사용하여 MMCSS에 등록됩니다.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

그림 A** Process Explorer에서 CPU Time(CPU 시간) 및 Cycles Delta(사이클 변화량) 보기 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 3 멀티미디어 클래스 스케줄러 오디오 작업 정의

그림 3** 멀티미디어 클래스 스케줄러 오디오 작업 정의 **(더 크게 보려면 이미지를 클릭하십시오.)

%SystemRoot%\System32\Mmcss.dll에서 구현되어 서비스 호스트(Svchost.exe) 프로세스에서 실행되는 MMCSS에는 우선 순위 27로 실행되는 우선 순위 관리 스레드가 있습니다. Windows의 스레드 우선 순위 범위는 0~31입니다. 이 스레드는 등록된 멀티미디어 스레드의 우선 순위를 해당 작업 레지스트리 키의 Scheduling Category 값과 연결된 범위로 높입니다(그림 4 참조). Windows에서 16 이상의 스레드 우선 순위는 실시간 우선 순위 범위에 해당하고 우선 순위 28과 29로 실행되는 커널의 메모리 관리자 작업자 스레드를 제외한 시스템의 다른 모든 스레드보다 우선 순위가 더 높습니다. MMCSS가 실행되는 로컬 시스템 계정과 같은 관리자 계정에만 실시간 스레드 우선 순위를 설정하는 데 필요한 우선 순위 높이기 권한이 있습니다.

Figure 4 MMCSS 스레드 우선 순위

사용 계획 범주 높아진 스레드 우선 순위
높음 23-26
보통 16-23

Windows Media Player에서는 사용자가 오디오 파일을 재생하면 오디오 작업 스레드를 등록하고 비디오를 재생하면 재생 작업 스레드를 등록합니다. MMCSS 서비스는 포그라운드 창을 소유한 프로세스에서 실행되고 있으며 BackgroundOnly 값이 해당 작업의 정의 키에 True로 설정되어 있는 상태로 스트림을 전달하고 있음을 나타내는 모든 스레드의 우선 순위를 높입니다.

그러나 MMCSS는 멀티미디어 스레드에 필요한 CPU 시간이 할당되도록 할 뿐만 아니라 다른 스레드에도 최소한 약간의 CPU 시간이 할당되도록 하여 시스템과 다른 응용 프로그램의 응답성이 유지되도록 합니다. 이를 위해 MMCSS는 다음 레지스트리 값에 지정된 비율의 CPU 시간을 다른 작업용으로 예약합니다.

HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness 

기본적으로 이 비율은 20%입니다. MMCSS는 CPU 사용을 모니터링하여 다른 스레드가 CPU 시간을 요구할 경우 10밀리초의 기간 중 8밀리초 이내로만 멀티미디어 스레드의 우선 순위를 높입니다. 나머지 2밀리초 동안에는 멀티미디어 스레드가 사용되지 않도록 하기 위해 스케줄러는 해당 스레드의 우선 순위를 1~7 범위로 낮춥니다.

MMCSS가 스레드 우선 순위를 높이는 방법에 대한 자세한 내용은 "MMCSS 우선 순위 높이기 관찰"을 참조하십시오.

파일 기반 심볼 링크

Windows Vista의 I/O 관련 변경 사항으로는 파일 기반 심볼 링크, 보다 효율적인 I/O 완료 처리, 포괄적인 I/O 취소 지원, 우선 순위가 부여된 I/O 등이 있습니다.

많은 사용자들이 NTFS에서 누락되었다고 생각하는 파일 시스템 기능인 심볼 파일 링크(UNIX에서는 소프트 링크라고 함)가 마침내 Windows Vista에 포함되었습니다. Windows 2000 버전의 NTFS에서는 다른 디렉터리를 가리키는 디렉터리를 만들 수 있게 해 주는 디렉터리 교차점이라는 심볼 디렉터리 링크가 사용되었지만 Windows Vista 이전 버전의 NTFS에서는 파일의 하드 링크만 지원했습니다.

Windows에서 심볼 링크와 디렉터리 교차점을 해결하는 방식의 가장 큰 차이점은 처리가 발생하는 위치입니다. Windows에서 심볼 링크는 원격 파일 서버에 있는 위치를 참조할 때조차 로컬 시스템에서 처리됩니다. Windows에서는 원격 파일 서버를 참조하는 디렉터리 교차점을 해당 서버 내에서 처리합니다. 따라서 서버에 있는 심볼 링크는 다른 클라이언트 볼륨과 같이 클라이언트에서만 액세스할 수 있는 위치를 참조할 수 있지만 디렉터리 교차점은 참조할 수 없습니다. 이 문제를 해결하기 위해 Windows Vista에서는 파일과 디렉터리 모두에 대해 새로운 심볼 링크 유형을 지원합니다.

심볼 링크에 내포된 의미를 이해할 수 있도록 다양한 파일 시스템 명령이 업데이트되었습니다. 예를 들어 Delete 명령은 링크를 따르는 대신 링크를 삭제하도록 업데이트되었습니다(링크를 따르면 대상이 삭제됨). 그러나 일부 응용 프로그램에서는 심볼 링크를 올바르게 처리할 수 없으므로 심볼 링크를 만들려면 기본적으로 관리자에게만 부여되는 새로운 심볼 링크 만들기 권한이 있어야 합니다.

Mklink 명령으로 명령 프롬프트에서 심볼 링크를 만들 수 있습니다. 명령 프롬프트에서 기본으로 제공하는 디렉터리 명령은 <SYMLINK>로 플래그를 지정하고 대상을 괄호 안에 표시하여 심볼 링크를 식별합니다(그림 5 참조). 심볼 링크는 Windows 탐색기에서도 확인할 수 있으며 바로 가기 화살표로 표시됩니다. 찾기 창에 링크 대상 열을 추가하여 탐색기에서 링크의 대상을 볼 수 있습니다.MMCSS 우선 순위 높이기 관찰

비디오 또는 오디오 클립 재생, 성능 모니터 실행, 그래프 배율을 31(Windows 스레드의 최고 우선 순위)로 설정, 표시 화면에 Windows Media Player(Wmplayer.exe) 스레드 개체의 모든 인스턴스에 대한 Priority Current 카운터 추가 등을 수행하여 MMCSS 서비스가 Windows Media Player 스레드에 적용하는 스레드 높이기를 확인할 수 있습니다. 하나 이상의 스레드가 우선 순위 21로 실행됩니다.

그림 B** Windows Media Player의 스레드 우선 순위 높이기 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 5 Mklink를 사용하여 심볼 링크 만들기

그림 5** Mklink를 사용하여 심볼 링크 만들기 **(더 크게 보려면 이미지를 클릭하십시오.)

I/O 완료 및 취소

I/O 시스템에는 사용자에게 보이지는 않지만 서버 응용 프로그램 성능을 향상시킬 수 있도록 다양한 기능이 변경되었습니다. 이러한 응용 프로그램에서는 완료 포트라는 동기화 개체를 자주 사용하여 비동기 I/O 요청이 완료될 때까지 대기합니다. Windows Vista 이전에는 이러한 I/O가 완료될 때 I/O를 호출한 스레드가 I/O 완료 작업을 실행하므로 해당 스레드가 속한 프로세스로 전환되고 진행되고 있던 다른 모든 작업이 중단됩니다. 그런 다음 I/O 시스템은 완료 포트의 상태를 업데이트하여 변경 대기 중인 스레드를 활성화합니다.

그러나 Windows Vista에서는 I/O를 호출한 스레드가 반드시 I/O 완료 처리를 수행하는 것이 아니라 완료 포트가 대기 상태를 해제해 주기를 기다리는 스레드가 I/O 완료 처리를 수행합니다. 비교적 간단해 보이지만 이러한 변경을 통해 응용 프로그램과 시스템의 전반적인 성능을 저하시킬 수 있는 불필요한 스레드 사용 계획과 컨텍스트 전환을 방지할 수 있습니다. 서버가 특정한 한 요청의 완료에서 여러 I/O 작업의 결과를 검색할 수 있으므로 커널 모드로의 전환이 방지되어 성능이 더욱 향상됩니다.

아마도 최종 사용자 측면에서 볼 때 I/O 시스템에서 가장 주목할 만한 변경 사항은 Windows Vista에서 동기 I/O 작업 취소가 지원된다는 것일 수 있습니다. net view 명령을 실행하거나 Windows XP 또는 Windows Server® 2003을 사용하여 오프라인 원격 시스템의 공유에 액세스하려고 시도하면 취소할 수 없는 I/O 작업으로 인해 문제가 발생하게 됩니다. 즉, 네트워크 시간 제한이 만료된 후에야 명령이나 파일 브라우저가 응답합니다. 응용 프로그램에서는 I/O를 실행하는 장치 드라이버에 더 이상 I/O에 대해 신경 쓰지 않음을 알릴 방법이 없기 때문에 작업이 실패할 때까지 기다릴 수 밖에 없습니다.

Windows Vista에서는 Net View와 탐색기에서 사용하는 열린 파일 I/O를 비롯하여 대부분의 I/O 작업을 취소할 수 있습니다. 그러나 응용 프로그램을 업데이트해야 I/O를 취소하라는 최종 사용자 요청에 응답할 수 있으며 시간 제한이 있는 장치와 상호 작용하는 많은 수의 Windows Vista 유틸리티에는 필요한 지원 기능이 있습니다. 예를 들어 이제는 타사 응용 프로그램을 포함하여 거의 모든 Windows 응용 프로그램에 사용되는 파일 열기 및 저장 대화 상자에 폴더 내용을 표시하면서 취소 단추를 사용할 수 있습니다. Net 명령의 동기 I/O도 Ctrl+C를 누르면 취소됩니다.

Windows Vista에서 명령 프롬프트를 열고 다음과 같이 입력하여 I/O 취소의 이점을 직접 확인할 수 있습니다.

net view (\\nonexistentmachine)

Windows에서 존재하지 않는 시스템에 연결을 시도할 때는 명령이 멈추지만 Ctrl+C를 누름으로써 명령을 종료할 수 있습니다. Windows XP에서는 Ctrl+C를 눌러도 아무 효과가 없으며 네트워크 작업 시간 제한이 만료되어야만 명령 결과가 반환됩니다.

이전 버전의 Windows에서 문제가 되었던 또 다른 유형의 I/O로는 장치 드라이버가 I/O를 취소하는 간단한 방법이 없어서 해당 장치 드라이버가 올바르게 취소하지 않은 I/O가 있습니다. 프로세스를 종료했지만 나중에 프로세스 보기 도구에서 해당 프로세스가 남아 있는 것을 확인한 경우 장치 드라이버가 프로세스 종료 명령에 응답하지 못하고 완료하지 못한 프로세스에서 호출한 I/O를 취소하는 것을 보게 됩니다. Windows에서는 모든 프로세스의 I/O가 완료되거나 취소된 후에만 최종 프로세스 정리를 수행할 수 있습니다. Windows Vista에서는 장치 드라이버가 프로세스 종료 알림을 손쉽게 등록할 수 있으므로 종료할 수 없는 프로세스 문제가 대부분 해결됩니다.

I/O 우선 순위

Windows에서는 항상 CPU 사용의 우선 순위 매기기를 지원해 왔지만 I/O 우선 순위 개념이 적용되지는 않았습니다. I/O 우선 순위가 없다면 검색 인덱싱, 바이러스 검색, 디스크 조각 모음과 같은 백그라운드 작업이 포그라운드 작업의 응답 성능에 심각한 영향을 미칠 수 있습니다. 예를 들어 다른 프로세스에서 디스크 I/O를 수행하는 동안 사용자가 응용 프로그램을 시작하거나 문서를 열면 포그라운드 작업이 디스크 액세스를 기다리므로 지연이 발생합니다. 동일한 간섭으로 인해 하드 디스크에 저장된 곡 등의 멀티미디어 콘텐츠를 스트리밍 재생할 때도 영향을 받습니다.

Windows Vista에서는 포그라운드 I/O 작업에 우선 순위를 부여하기 위해 새로운 유형의 두 가지 I/O 우선 순위인 개별 I/O 작업 및 I/O 대역폭 예약에 대한 우선 순위가 새롭게 구현되었습니다. Windows Vista I/O 시스템에서는 내부적으로 그림 6에 표시된 5가지 I/O 우선 순위를 지원하지만 이 중에서 4개의 우선 순위만 사용됩니다. 이후 버전의 Windows에서는 높음을 지원할 수도 있습니다.

Figure 6 Windows Vista I/O 우선 순위

I/O 우선 순위 사용량
중요 메모리 관리자
높음 사용 안 함
보통 기본 우선 순위
낮음 기본 작업 우선 순위
매우 낮음 백그라운드 작업

I/O의 기본 우선 순위는 보통입니다. 메모리 관리자는 메모리가 부족한 상황에서 다른 데이터와 코드에 메모리를 할당할 공간을 확보하기 위해 더티 메모리 데이터를 디스크에 기록하려는 경우 중요를 사용합니다. Windows 작업 스케줄러는 기본 작업 우선 순위가 있는 작업의 I/O 우선 순위를 낮음으로 설정하며 백그라운드 처리를 수행하는 Windows Vista용 응용 프로그램에서 지정하는 우선 순위는 매우 낮음입니다. Windows Defender 검색과 데스크톱 검색 인덱싱을 포함한 모든 Windows Vista 백그라운드 작업은 매우 낮음 I/O 우선 순위를 사용합니다.매우 낮음 I/O 우선 순위 보기

Sysinternals의 실시간 파일 시스템 및 레지스트리 모니터링 유틸리티인 Process Monitor는 Windows Vista에서의 I/O 우선 순위를 포함하여 읽기 및 쓰기 파일 시스템 작업에 대한 자세한 정보를 수집합니다. 강조 표시된 줄은 다음 호에서 살펴볼 SuperFetch에서 호출한 매우 낮음 우선 순위 I/O의 예를 보여 줍니다.

그림 C** Proces Monitor에서 매우 낮음 I/O 우선 순위 보기 **(더 크게 보려면 이미지를 클릭하십시오.)

시스템 저장소 클래스 장치 드라이버(%SystemRoot%\System32\Classpnp.sys)가 I/O 우선 순위를 적용하므로 대부분의 저장 장치로 향하는 I/O에 이러한 우선 순위가 자동으로 적용됩니다. 클래스 및 다른 저장소 드라이버는 해당 큐에서 우선 순위가 낮음 및 매우 낮음인 이러한 I/O 앞에 보통 I/O를 삽입하지만 1초마다 적어도 하나의 대기 중인 낮음 또는 매우 낮음 I/O를 호출하므로 백그라운드 프로세스는 큐에서 앞으로 진행될 수 있습니다. 또한 매우 낮음 I/O를 사용하여 데이터를 읽으면 캐시 관리자가 나중에 쓰지 않고 즉시 디스크에 수정 내용을 쓰며 액세스되고 있는 파일에서 우선적으로 읽는 읽기 작업의 미리 읽기 논리를 무시합니다. Process Monitor 유틸리티를 사용한 매우 낮음 I/O 우선 순위의 예를 보려면 "매우 낮음 I/O 우선 순위 보기"를 참조하십시오.

Windows Vista 대역폭 예약 지원은 미디어 플레이어 응용 프로그램에 유용하며 Windows Media Player에서는 이 기능을 MMCSS 우선 순위 높이기 기능과 함께 사용하여 로컬 콘텐츠를 오류 없이 재생합니다. 미디어 플레이어 응용 프로그램에서는 지정한 속도로 데이터를 읽을 수 있도록 I/O 시스템에 요청하며, 장치가 요청한 속도로 데이터를 전달할 수 있고 기존 예약에서 이를 허용할 경우 응용 프로그램에 I/O 호출 속도와 I/O 크기에 대한 지침을 제공합니다. 대상 저장 장치에서 예약을 한 응용 프로그램의 요구 사항을 충족할 수 없는 경우 I/O 시스템에서는 다른 I/O를 처리하지 않습니다.

I/O 시스템에서 주목할 만한 또 다른 최종 변경 사항 중 하나는 I/O 작업의 크기와 관련이 있습니다. Windows NT의 첫 번째 버전 이후로 메모리 관리자와 I/O 시스템에서는 개별 저장소 I/O 요청으로 처리되는 데이터 양을 64KB로 제한합니다. 따라서 응용 프로그램에서 훨씬 더 많은 I/O 요청을 호출하면 해당 요청은 최대 크기가 64KB인 개별 요청으로 나뉩니다. 각 I/O가 커널 모드로의 전환에 따른 오버헤드를 발생시키고 저장 장치에서 I/O 전송을 시작하므로 Windows Vista에서는 저장소 I/O 요청의 크기에 더 이상 제한이 없습니다. 이제 1MB의 I/O를 호출하는 탐색기의 복사 기능과 명령 프롬프트의 Copy 명령을 포함하여 보다 큰 I/O에 대한 지원을 활용하도록 여러 가지 Windows Vista 사용자 모드 구성 요소가 수정되었습니다.

다음 문서에서 다룰 내용

지금까지 Windows Vista 커널에서 향상된 두 가지 영역을 살펴봤습니다. 코드명이 "Longhorn"인 다음 Windows Server 버전과 동시에 출시할 예정으로 집필한 Windows Internals(David Solomon 공저)의 다음 판본에서는 더 깊이 있는 내용을 보실 수 있습니다. 다음 호에서는 메모리 관리와 시스템 시작 및 종료에 대한 논의를 통해 계속해서 새 커널에 대해 소개할 것입니다.

Mark Russinovich는 Microsoft의 플랫폼 및 서비스(Platform and Services) 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 IT와 개발자 회의에 자주 서는 연설자이며 최근 Microsoft에서 인수한 Winternals Software의 공동 설립자이기도 합니다. 그는 또한 Process Explorer, Filemon 및 Regmon 유틸리티를 게시한 Sysinternals를 설립했습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..