Solaris Slab Allocator –Magazines[1]

Overview
전형 적 인 slab allocator 알고리즘 은 다 중 CPU 시스템 에서 scalability 가 좋 지 않 습 니 다. slab list 는 전체 구조 이기 때문에 분배 와 방출 할 때 global lock 이 list 데 이 터 를 보호 해 야 합 니 다. 이것 은 모든 분배 작업 을 선형 화 하 는 것 과 같 습 니 다.이 부족 함 을 보완 하기 위해 Solaris 는 per - CPU cache 의 전략 을 제시 했다.기본 사상 은 모든 CPU 에 M 개의 Object 를 수용 할 수 있 는 Cache 를 유지 하 는 것 이다. 매 거 진 이 라 고 부 르 는데 매 거 진 은 잡지 의 뜻 을 제외 하고 '탄약 고' 라 는 뜻 도 있다.자원 배분 시 이 Magazine Layer 에 먼저 신청 합 니 다. Magazine Layer 가 비어 있 으 면 Magazine Layer 는 자동 으로 탄약 reload 를 채 웁 니 다!
다음 그림 은 전체 절 차 를 보 여 줍 니 다.
다 중 CPU 의 성능 을 개선 하기 위해 Slab Layer 에 Magazine Layer 를 추 가 했 습 니 다. Magazine Layer 는 2 층, CPU Layer 와 Depot Layer 가 있 습 니 다.cachecpu 는 CPU 마다 하나 입 니 다. 현재 cachecpu 는 자원 배분 수 요 를 만족 시 킬 수 있 으 므 로 involve 전역 잠 금 이 필요 없습니다.
cache 로cpu [0] 는 사실 두 개의 Magazine: loaded 와 Previous 를 유지 하고 있 습 니 다. 그림 의 모든 magazine 은 8 개의 크기 가 같은 objects 를 수용 할 수 있 습 니 다.이곳 의 실현 은 매 거 진 마다 M 개의 지침 을 가 진 array 이다.그 행 위 는 stack 과 유사 하 다.
분배: obj = magazine [-- rounds];방출:   magazine[rounds++] = obj;
저 는 magazine 의 정 의 를 내 립 니 다. [open solaris, 소스 코드 를 공개 해 주 셔 서 감사합니다.]
typedef struct umem_magazine {      void    *mag_next;      void    *mag_round[1];         /* one or more rounds */ } umem_magazine_t;

      solaris       mag_round[1]   objects     list? 

4. 567917. slab allocator 의 중심 사상 중 하 나 는 바로 분배 할 때 '준 비 된 constructed' object 를 직접 받 기 를 바 라 는 것 이다.listing 을 사용 하면 링크 된 object 의 데이터 구조 에 object * 지침 이 포함 되 어 있 습 니 다.그래서 매번 분배 와 방출 할 때마다 object 내부 에 있 는 지침 을 수정 해 야 한다.이렇게 하면 constructed 의 원시 상 태 를 파괴 하고 분배 와 방출 에 추가 적 인 부담 을 준다
4. 567917. slab allocator 의 디자인 취 지 는 '모든' 자원 을 관리 할 수 있다 는 것 이다.관 리 된 자원 object 가 모두 writable memory 는 아 닙 니 다
다음 편 에 서 는 솔 라 리 스 의 매 거 진 이 '떨 림 thrashing' 문 제 를 어떻게 극복 하여 cache 의 missing rate 가 1 / M 보다 높 지 않 게 하 는 지 소개 하 겠 습 니 다.
관심 이 있 는 학생 은 영어 원문 을 참고 할 수 있다.
Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources.