RAM보다 빠른 속도로 리눅스를 실행할 수 있습니까?


21

이것은 어리석은 질문 일 수 있으며 오해의 결과 일 수 있습니다. 나는 지금 CPU와 특히 메모리를 연구하고 있습니다. 나는 SRAM이 DRAM보다 얼마나 빠르지 만 더 비싸다는 것을 읽었습니다. SRAM은 매우 비싸다 : 나는 조금 쇼핑하고 16MB의 배터리로 구동되는 SRAM 카드를 약 400 달러에 찾았다.

최근 한 친구가 자신이 강아지 리눅스를 RAM으로 돌리고 있다고 말하면서 빠르다. 그래도 작은 코어 리눅스는 8MB 정도로 작아 질 수 있습니다! 우리는 SRAM에서 리눅스를 실행할 수 있습니까? 그 질문은 잘 구성되어 있습니까?

이 질문을 검색하면 효과가 없었지만 더 많은 질문이 제기되었습니다. L3 캐시에서 리눅스를 실행할 수 있습니까? Intel Core i7은 8MB에 맞도록 L3 캐시를 가질 수 있지만 범주 오류가 있습니까? 이것과 '내장'리눅스의 차이점은 무엇입니까?

그것은 SRAM 또는 L3 캐시에서 리눅스를 실행할 수 있습니까? 더 빠른 것이 있습니까? 우리는 얼마나 빨리 리눅스를 할 수 있습니까!?

지.


3
임베디드 리눅스는 종종 램 또는 비 휘발성 메모리에서 실행됩니다. 임베디드 리눅스는 종종 특정 하드웨어에서만 실행되도록 설정되거나 지연 시간이 짧은 것과 같은 덜 일반적인 커널 옵션을 사용합니다.
Journeyman Geek

2
이 질문에 실용적인 용도가 있는지 궁금합니다.
Robert Niestroj 2015 년

4
"linux"를 동사로 사용해서 +1 (마지막 문장)!
Vorac

답변:


20

Linux 또는 다른 OS는 RAM 작동 방식을 모릅니다. 메모리 컨트롤러가 올바르게 구성되어있는 한 (예 : 비 SRAM에 대해 새로 고침 빈도 설정) OS는 C64-ish의 일반 동적 메모리 (일반 RAM), 고속 페이지 모드 RAM (FP RAM)에서 실행되는 것을 신경 쓰지 않습니다. 시간), 확장 데이터 출력 모드 RAM (EDO), 동기 RAM (SDRAM), 이중 데이터 전송 속도 SDRAMS (DDR 1/2/3) 중 무엇이든 상관 없습니다.

이 모든 것들은 임의의 장소에서 읽고 쓰는 것을 지원합니다. 모두 작동합니다.

이제 캐시는 약간 다릅니다. 내용을 변경하기 위해 쓰지 않아도됩니다. 그렇게 될 것입니다. 그래도 다소 사용할 수 있습니다. 메모리 컨트롤러가 올바르게 구성되기 전에 coreboot가 부팅 중에 캐시를 일종의 메모리로 사용한다는 것을 알고 있습니다. (자세한 내용은 FOSDEM 2011 중 코어 부트 토크의 비디오를 확인하십시오).

따라서 이론적으로는 사용할 수 있습니다.

그러나 실제 작업의 경우 1GB의 '일반' '중간 속도'메모리가있는 시스템은 몇 MB의 초고속 메모리보다 성능이 훨씬 뛰어납니다. 이는 세 가지 선택이 있음을 의미합니다.

  1. 정상적인 '저렴한'방식으로 물건을 만드십시오. 더 빠른 속도를 원한다면 수십 개의 추가 컴퓨터를 추가하십시오 (모두 '느린'메모리 사용)
  2. 또는 가격이 수십 배, 성능은 수십 배 미만인 단일 컴퓨터를 구축하십시오.

매우 드문 경우를 제외하고 마지막은 합리적이지 않습니다.


6
많은 CPU는 CPU의 MSR (Model Specific Register)을 통해 "RAM으로 캐시"모드를 지원합니다. 또한 SRAM은 DRAM보다 더 많은 전력을 소비하며 이는 설계 요소이기도합니다. CPU 캐시가 충분히 크거나 커널이 충분히 작 으면이 RAM을 캐시 모드로 설정하여 CPU의 SRAM에서 완전히 실행되도록 할 수 있습니다. 그러나 프로그램 등을 실행하는 데는 RAM 용량이 제한되어 있습니다. AFAIK RAM 캐시와 일반 모드가 동시에 작동하지 않기 때문입니다. 그래도 나는 틀릴 수 있습니다. 그렇더라도 요즘 CPU 속도의 대부분은 L2, L3 캐시를 사용하기 때문입니다.
LawrenceC

@Hennes 리눅스가 (매핑 된) 메모리 주소 만 신경 쓰는가?
Alvin Wong

SDRAM은 동기식 D (동적) RAM 인 반면 SRAM은 정적 RAM입니다. 첫 번째 단락에서 어떤 단어를 언급했는지 모르고 "사소한"편집을 할 담당자가 없지만 어쩌면 고칠 수 있습니까? 그 외에는 좋은 대답입니다.
CVn

명확하게 설명하지는 않지만 명확하게 설명하고 싶은 것이 확실하지 않습니다. 주석에 추가하면 편집 할 수 있습니다.
Hennes

이 주석을 처음 읽었을 때 "Linux 또는 다른 OS는 RAM의 작동 방식을 모르고 죽었습니다." 당신의 고장은 좋은 것입니다 : 나는 이것이 "더 좋을 것"이라는 환상이 없다고 생각합니다. 나는 그것이 가능한지 궁금했다.
Ziggy

8

예, 가능합니다. 실제로 자동으로 이미 수행 된 방식입니다. RAM에서 가장 자주 사용되는 부분은 캐시에 복사됩니다. 총 RAM 사용량이 캐시 크기보다 작 으면 (기존대로) 기존 캐싱 메커니즘이 RAM의 모든 내용을 복사합니다.

캐시가 일반 RAM으로 다시 복사되는 유일한 시간은 PC가 S3 절전 모드로 전환되는 시점입니다. 캐시는 S3 모드에서 전원이 꺼지기 때문에 필요합니다.


1
모든 것이 복사 될 수있는 것은 아닙니다. Intel / x86 캐시 구조 : 256KiB 캐시 및 1024KiB 캐시가있는 경우 주소 0을 읽을 수 있습니다. 주소 0의 캐시에 저장됩니다. 그런 다음 주소 1을 읽을 수 있으며 위치 1의 캐시에 저장됩니다. 그러나 (256Kib + 1)에서 주소를 읽으면 캐시의 주소 1에도 저장됩니다. 캐시는 여분의 (태그) SRAM을 사용하여 둘 중 어느 것이 저장되는지 나타냅니다. 이는 여러 캐시 크기에서 읽는 것이 제대로 작동하지 않음을 의미합니다. (이것은 드문 일이며 일반적으로 무시할 수 있습니다).
Hennes

통찰력이 있습니다! 천재 군이 최적의 행동을 결정하고 CPU가 최적의 행동을 할 수 있도록 L3 캐시에 중요하다고 생각하는 것을 서투른 방식으로 채우는 이유는 무엇입니까? 권리?
Ziggy

3

많은 CPU에서 캐시를 RAM으로 사용할 수 있습니다. 예를 들어, 대부분의 최신 x86 CPU는 MTRR을 통해 읽기를 채우지 않고 특정 영역을 후기 입으로 구성 할 수 있습니다. 이것은 주소 공간의 영역을 효과적으로 캐시로 캐시로 지정하는 데 사용될 수 있습니다.

이것이 유익한 지 여부는 또 다른 질문입니다-커널을 RAM에 고정시키는 동시에 캐시의 유효 크기를 줄입니다. 또한 시스템 속도를 늦추는 부작용 (예 : 나머지 시스템에서 캐싱을 비활성화해야 함)이있을 수 있습니다.


2

"L3 캐시에서 리눅스를 실행할 수 있습니까?"

아니요 , 캐시 메모리가 직접 / 선형으로 지정되지 않았기 때문에 불가능합니다.
캐시 메모리의 설계 방식으로 인해 CPU 프로그램 카운터 (IP) 레지스트리 는 캐시 메모리의 위치를 ​​가리킬 수 없습니다.

CPU 캐시에는 자체 "연결성" 이 있으며이 연관성으로 인해 "일반"메모리가 캐시 메모리에 "매핑"되는 방식이 정의됩니다. 캐시 메모리의이 기능은 캐시 메모리가 너무 빠른 이유 중 하나입니다.


1

"L3 캐시에서 리눅스를 실행할 수 있습니까?"

아니요, 캐시에는 프로세서가 필요할 때 준비 할 수있는 프로그램 데이터와 명령어를 보관하는 특정 작업이 있습니다. 어쨌든 끊임없이 사용되기 때문에 캐시에서 운영 체제를 찾을 수 있습니다. 커널의 모든 코드 경로를 한 번에 사용하지 않기 때문에 모든 OS를 캐시에로드하는 것은 효율적이지 않습니다.

"SRAM에서 리눅스를 실행할 수 있습니까?"

확실히 배터리 백업 SRAM을 부팅 파티션으로 사용할 수 있으며 내장 된 실행 플래그를 사용할 수 있습니다. 부팅 시간이 단축되고 작업 속도가 약간 빨라질 수 있습니다. 그러나 주요 요인은 L3 캐시와 커널 위치 (부트 드라이브 또는 RAM) 간의 대역폭입니다.

"더 빠른 것이 있습니까? 얼마나 빨리 리눅스를 사용할 수 있습니까?"

일반적으로 하드웨어 제조업체와 운영 체제 개발자는 처리 속도를 최대한 높이기 위해 노력하고 있습니다. 그러나 귀하의 질문은 매우 일반적입니다. 부팅 시간을 단축하고 파일 시스템 액세스를 최적화하며 계산 속도를 높이고 싶습니까? 보다 구체적인 질문이 있으면 병목 현상을 찾아 제거 할 수 있습니다. SRAM 드라이브는 확실히 부팅 속도를 높입니다. 3 초 안에 GUI에 접근하는 것은 매우 시원 할 것입니다.


1

486 년대에 모든 RAM이 SRAM 인 머신이있었습니다. 이것은 8MB가 많았을 때 돌아 왔지만 제약 조건과 일치하는 것 같습니다. 나는 지금보다 8MB의 SRAM이 훨씬 저렴하다고 확신합니다.

따라서 머신을 그렇게 만든 경우 SRAM에서 Linux를 실행할 수 있습니다. 이론이 아닙니다. 끝났습니다.

그러나 캐시에는 없습니다. 캐시는 다르게 연결되어 있으며 더 중요하게 다르게 처리됩니다. 당신은 그것을 동일하게 해결할 수 없습니다. 청크는 연속적인 청크가 아닌 다르게 매핑됩니다. 그리고 내용은 반드시 디스크에서 볼 필요는 없습니다. 최신 인텔 칩은 마이크로 컴이있는 곳에서 "컴파일"(CISC => RISC- 마이크로 -op 재 인코딩)의 일종입니다. 캐시로 끝납니다. 간단히 말해서, 캐시에있는 것은 프로그램이 아니라 변경된 뷰이므로 더 이상 프로그램의 메모리 표현으로 사용할 수 없습니다.

문제는 이유입니다. "할 수 있기 때문에"이외에는 그럴만 한 이유가 없습니다. 캐시 시스템은 훨씬 적은 비용으로 대부분의 속도 이점을 제공합니다. 비용은 단지 달러가 아니라는 것을 기억하십시오. SRAM은 더 많은 트랜지스터를 사용하므로 더 많은 전기를 소비합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.