스왑 공간은 두 가지 이유 때문에 필요하다.
(1) 우리가 프로세스 전체를 스왑 아웃할 필요가 있을 경우 그 프로세스의 모든 페이지가 디스크에 저장되어야 한다.
(2) 프로세스의 각 페이지가 주 메모리에서 제거될 필요가 있을 경우이며, 이때 제저될 내용을 저장할 장소가 필요한데, 이를 스왑을 사용한다.
스왑은 하나 또는 그 이상의 논리적 디스크 파티션이 어떤 용도로 예약된다. 이 파티션들은 미가공(raw) 상태이다. 즉, 파일 시스템이 없다. 4BSD는 페이징 성능을 향상시키기 위해 여러 디스크 상에 스왑 파티션을 허용한다. 이 파티션들은 하나의 스왑 파티션으로 사용되기 위해 논리적으로 서로 교대로 끼여(interleave) 놓여진다. 이것은 모든 파티션에 스와핑 부하를 공평하게 분배한다. 스왑 공간에서 페이지의 위치는 논리적 스왑 파티션을 나타내는 유사 디바이스 번호와 그 디바이스 파티션 내의 오프셋으로 결정된다. 이것은 내부적으로 적절한 물리 파티션과 그 파티션에서의 오프셋으로 변환된다. 이것은 내부적으로 적절한 물리 파티션과 그 파티션에서의 오프셋으로 변환된다.
엄밀히 말해, 스왑 공간은 스왑 아웃될 필요가 있는 페이지에 대해서만 할당 받으면 된다. 그러한 도전적인 정책의 결과로 메모리의 과약속(overcommit)이 발생해, 임의의 순간에 프로세스의 스왑 공간이 부족해 질 수 있다. 예를 들어, 만약 그것이 정상적인 프로그램 수행 중에 발생 한다면 그 프로그램이 예기치 않게 종료하거나 중지될 지 모른다. 이를 피하기 위해, 4.3BSD는 매우 보수적인 스왑 할당 정책을 강요한다. 한 프로세스가 시작할 때, 커널은 그 데이터와 스택 영역을 위해 필요한 모든 스왑 공간을 할당한다. 스왑 공간은 하나의 큰 덩어리로 할당되어, 약간 확장 할 수 있는 여지가 있다. 그러나 영역(region)이 그 덩어리보다 더 커지면 영역(region)이 성장하도록 허락하기 전에 더 많은 스왑 공간을 할당해야 한다. 이 정책은 스오바 공간의 부족이, 영역(region)의 생성 시 또는 확장 시라는 잘 정의된 곳에서만 발생하게 한다.
텍스트 페이지(그리고 변경되지 않은 데이터 페이지)는 스왑 아웃될 필요가 없다. 왜냐하면 그들은 실행 파일로부터 다시 가져올 수 있기 대문이다. BSD 구현에서 이는 문제점이다. 왜냐하면 파일에서 메모리로 불러오게 되면, 그 정보는 페이지 프레임 번호로 덮어 쓰여진다. 그 결과 그 페이지를 파일로부터 다시 얻는 것은 그 위치를 다시 계산하고, 때로는 하나 이상의 간접 블록을 접근해야 한다. 이것은 매우 비용이 크므로, 이를 피하기 위해 그런 페이지들 역시 스왑 공간에 저장된다. 만약 여러 프로세스가 같은 프로그램을 실행하고 있다면, 스왑 공간 상에 텍스트 영역의 복사본이 단지 하나만 필요하다. 텍스트 영역은 크기가 고정적이므로 텍스트를 위한 스왑 공간은 하나의 연속적인 덩어리로 할당 될 수 있다. 이것은 여러 개의 인접한 페이지가 하나의 연산으로 함께 읽혀지도록 해준다.
커널은 스왑 공간 할당을 영역 별 dmap 구조체에 기록한다. 한 영역에 ㅏㄹ당된 첫번째 덩어리는 크기가 dmmin(전형적으로 16KB)이다 이어지는 덩어리는 크기가 dmmax(전형적으로 0.5 ~ 2MB)에 이를 때까지 앞의 것의 크기의 2배이다. 그 이후로의 모든 덩어리는 크기가 dmmax이다. 으메 구조체는 일정 크기의 배열이다. 배열의 각 원소는 스왑 디바이스 상에서 그 덩어리의 시작주소를 갖고 있다. 그 원소의 인덱스는(dmmin과 dmmax와 함께) 덩어리의 크기로 변환된다. 으메 배열의 크기는 고정적이어서 데이터 또는 스택 영역의 최애 허영 크기에 강한 제한을 준다. u에리어(area)는 데이터와 스택 영역을 위한 맵들을 갖고 있다. 텍스트 영역은 크기가 정해여 있어서 다른 방법으로 맵된다. 텍스트는 공유하는 프로세스의 수에 관계없이 오직 하나의 복사판만 디스크에 저장되면 된다. 따라서, 스왑 맵은 텍스트 구조의 일부이다. 할당은 고정 크기인 dmtext(통상 512KB)의 덩어리로 행해지며, 마지막 덩어리는 사용된다.
[펌] - 솔라리스 전문가
(1) 우리가 프로세스 전체를 스왑 아웃할 필요가 있을 경우 그 프로세스의 모든 페이지가 디스크에 저장되어야 한다.
(2) 프로세스의 각 페이지가 주 메모리에서 제거될 필요가 있을 경우이며, 이때 제저될 내용을 저장할 장소가 필요한데, 이를 스왑을 사용한다.
스왑은 하나 또는 그 이상의 논리적 디스크 파티션이 어떤 용도로 예약된다. 이 파티션들은 미가공(raw) 상태이다. 즉, 파일 시스템이 없다. 4BSD는 페이징 성능을 향상시키기 위해 여러 디스크 상에 스왑 파티션을 허용한다. 이 파티션들은 하나의 스왑 파티션으로 사용되기 위해 논리적으로 서로 교대로 끼여(interleave) 놓여진다. 이것은 모든 파티션에 스와핑 부하를 공평하게 분배한다. 스왑 공간에서 페이지의 위치는 논리적 스왑 파티션을 나타내는 유사 디바이스 번호와 그 디바이스 파티션 내의 오프셋으로 결정된다. 이것은 내부적으로 적절한 물리 파티션과 그 파티션에서의 오프셋으로 변환된다. 이것은 내부적으로 적절한 물리 파티션과 그 파티션에서의 오프셋으로 변환된다.
엄밀히 말해, 스왑 공간은 스왑 아웃될 필요가 있는 페이지에 대해서만 할당 받으면 된다. 그러한 도전적인 정책의 결과로 메모리의 과약속(overcommit)이 발생해, 임의의 순간에 프로세스의 스왑 공간이 부족해 질 수 있다. 예를 들어, 만약 그것이 정상적인 프로그램 수행 중에 발생 한다면 그 프로그램이 예기치 않게 종료하거나 중지될 지 모른다. 이를 피하기 위해, 4.3BSD는 매우 보수적인 스왑 할당 정책을 강요한다. 한 프로세스가 시작할 때, 커널은 그 데이터와 스택 영역을 위해 필요한 모든 스왑 공간을 할당한다. 스왑 공간은 하나의 큰 덩어리로 할당되어, 약간 확장 할 수 있는 여지가 있다. 그러나 영역(region)이 그 덩어리보다 더 커지면 영역(region)이 성장하도록 허락하기 전에 더 많은 스왑 공간을 할당해야 한다. 이 정책은 스오바 공간의 부족이, 영역(region)의 생성 시 또는 확장 시라는 잘 정의된 곳에서만 발생하게 한다.
텍스트 페이지(그리고 변경되지 않은 데이터 페이지)는 스왑 아웃될 필요가 없다. 왜냐하면 그들은 실행 파일로부터 다시 가져올 수 있기 대문이다. BSD 구현에서 이는 문제점이다. 왜냐하면 파일에서 메모리로 불러오게 되면, 그 정보는 페이지 프레임 번호로 덮어 쓰여진다. 그 결과 그 페이지를 파일로부터 다시 얻는 것은 그 위치를 다시 계산하고, 때로는 하나 이상의 간접 블록을 접근해야 한다. 이것은 매우 비용이 크므로, 이를 피하기 위해 그런 페이지들 역시 스왑 공간에 저장된다. 만약 여러 프로세스가 같은 프로그램을 실행하고 있다면, 스왑 공간 상에 텍스트 영역의 복사본이 단지 하나만 필요하다. 텍스트 영역은 크기가 고정적이므로 텍스트를 위한 스왑 공간은 하나의 연속적인 덩어리로 할당 될 수 있다. 이것은 여러 개의 인접한 페이지가 하나의 연산으로 함께 읽혀지도록 해준다.
커널은 스왑 공간 할당을 영역 별 dmap 구조체에 기록한다. 한 영역에 ㅏㄹ당된 첫번째 덩어리는 크기가 dmmin(전형적으로 16KB)이다 이어지는 덩어리는 크기가 dmmax(전형적으로 0.5 ~ 2MB)에 이를 때까지 앞의 것의 크기의 2배이다. 그 이후로의 모든 덩어리는 크기가 dmmax이다. 으메 구조체는 일정 크기의 배열이다. 배열의 각 원소는 스왑 디바이스 상에서 그 덩어리의 시작주소를 갖고 있다. 그 원소의 인덱스는(dmmin과 dmmax와 함께) 덩어리의 크기로 변환된다. 으메 배열의 크기는 고정적이어서 데이터 또는 스택 영역의 최애 허영 크기에 강한 제한을 준다. u에리어(area)는 데이터와 스택 영역을 위한 맵들을 갖고 있다. 텍스트 영역은 크기가 정해여 있어서 다른 방법으로 맵된다. 텍스트는 공유하는 프로세스의 수에 관계없이 오직 하나의 복사판만 디스크에 저장되면 된다. 따라서, 스왑 맵은 텍스트 구조의 일부이다. 할당은 고정 크기인 dmtext(통상 512KB)의 덩어리로 행해지며, 마지막 덩어리는 사용된다.
[펌] - 솔라리스 전문가
'9. 도서관 > __다. UNIX' 카테고리의 다른 글
cp [파일 복사] /bin/cp (0) | 2008.07.10 |
---|---|
solaris Erro message set (0) | 2008.07.03 |
콘쉘 ( Korn shell ) (0) | 2008.07.03 |
disksuite 로 구성한 RAID 볼륨을 다른 시스템에 mount 하려면? (0) | 2008.07.02 |
[Solaris_Basic] RAID 구성 (0) | 2008.07.02 |
댓글