당연히 논리적으로 충분히 가능합니다.
write-through에서 write-allocation을 사용할 때의 장단점은 다음과 같습니다.
장점: write 후 read 시 캐시를 사용하므로 빨라집니다.
단점: write 후 read를 하지 않는 경우 eviction이 낭비됩니다. 즉 사용할 캐시 영역이 줄어드는 단점이 발생합니다.
리눅스는 메모리에 대한 기본 매핑으로 가장 빠른 방법을 사용하고 Armv6에서는 Write-Back, Armv7에서는 Write-Back Write-Allocation을 기본으로 사용하고 있습니다. 디바이스에서 사용할 reserved 영역들을 위해 다른 종류의 매핑을 사용하기도 하는데 이 때에 사용하는 API로 ioremap()을 사용합니다. 참고: http://jake.dothome.co.kr/ioremap
답변감사합니다.
Write-back 방식 기본으로 설정이 되어있으면 write-through 방식으로 사용자가 변경할수있는 다른 방법이 있을까요(커널단에서의 설정변경이나 bios를 통한방법으로도 변경가능한지 궁금해서요)
Write-back 방식의경우 Dirty cache를 clean할때 io_wait를 발생시키는것같아서.. io_wait를 발생을 회피할수있는 write-through방식으로 app을 구동하고싶어서 문의를 드립니다.
application 마다 캐시 특성을 바꾸는 방법은 커널이 지원하지 않습니다.
예를 들어 abc 파일을 하나의 application에서 write back으로 매핑하여 사용하고,
두 번째 application에서 non cache로 매핑하여 사용하는 경우,
캐시 일관성 문제가 발생합니다.
따라서 일반 메모리는 한꺼번에 같은 방식의 메모리 캐시 타입으로 매핑해서 사용해야 합니다.
커널 메모리 전체를 일부러 다른 방식으로 매핑하려면 커널의 헤더 파일 일부를 수정하면 간단합니다.
다만 위에서 언급한 것처럼 특정 application에 대해 변경하려고 하면 그만한 문제점이 발생합니다.
DMA 디바이스에서는 특정 영역의 메모리에 대해 캐시 타입을 바꿔서 사용하기도 합니다.
물론 커널에서는 이 영역을 미리 reserve하여 일반 캐시를 사용하는 메모리 매핑을 하지 않았을 것이고 원하는 캐시 타입으로 매핑하여 사용할 수도 있습니다.
그것을 설명한 것이 ioremap() 함수였습니다.
자세한 설명 감사합니다.
App별로 설정을 다르게할수는없겠군요
그럼 커널 전체의 메모리를 write-through방식으로 변경을 해보려고하는데요 혹시 어떤 헤더파일을 확인하면 되는지 알수가 있을까요
그리고 DMA디바이스의 경우 어떤식으로 캐시타입을 변경하는지 궁금합니다. 변경하는 이유는 아직 메모리에 옮겨지지않은 캐시 내 정보를 DMA디바이스가 찾질못하기 때문인가요?
으로 uncached, buffered, writethrough, writeback, writealloc 등 5개의 항목이 지정될 수 있습니다.
참고로 armV6 아키텍처의 default는 writeback이고, armV7 아키텍처의 default는 writealloc입니다. (write-back & write-alloc)
DMA 디바이스는 cpu가 특정 메모리를 캐시해서 사용하는지 안하는지 모릅니다. 그냥 메모리에 읽고 쓰고만 합니다.
따라서 cpu가 DMA 디바이스가 사용하는 영역을 캐시하지 않는 경우 캐시 불일치등의 트러블이 발생하지 않습니다. 다만 캐시를 사용하지 않아 매우 느립니다.
성능이 중요 시 되는 장치라고 판단되면 DMA 디바이스가 사용하는 메모리도 캐시를 적용해야 cpu에서 해당 메모리에 대한 접근이 빈번할 경우 성능을 기대할 수 있습니다. 다만 캐시된 정보는 DMA 디바이스가 인지하지 못하므로 cpu와 dma 디바이스간의 읽고 쓰는 처리 방법에 대해 서로 약속을 해야 합니다.
cpu가 기록한 정보들은 캐시를 clean 한 후에만 디바이스가 읽어가게 한다든지 소프트웨어 적인 기법으로 캐시 일관성 문제를 해결해야합니다.
cache coherent & dma 등으로 검색하시면 정확한 이유 등을 알아보실 수 있을 것입니다. 다만 매우 복잡합니다.
궁금한 부분들을 쉽게 설명해주셔서 감사합니다.
알려주신 방법으로 메모리 사용방식을 변경해보려고 하는데요 변경 후에 적용이 정상정으로 되어있는지 확인할수있는 부분이 있나요?
제가한 방법은 sysctl. conf파일에 cachepolicy=writethrough를 추가하고 서버리붓을 하는방법이었는데요. 리붓후에 확인해보니 여전히 writeback방식을 사용하고 있었습니다. 커널로그에서는 cachepolicy관련 정보가 없는것 같은데 다른부분에서 적용 확인이 가능한곳이 있을까요
커널 파라메터 또는 부트 파라메터라고도 불리는데 이것 들을 입력하는 곳은 총 3군데 중 하나를 고쳐야 합니다.
1) uboot 설정
– 정확히 기억이 나지 않습니다.
2) 커널 설정
– menuconfig에서 설정
3) 디바이스 트리를 사용하는 경우 디바이스 트리에 설정
– /chosen 노드의 bootargs 속성으로 설정할 수 있습니다.
관련 커널 컴파일 옵션: CONFIG_CMDLINE, CONFIG_CMDLINE_FORCE
부팅 후 커널 파라메터가 제대로 입력되었었는지 여부를 확인하려면 다음과 같이합니다.
$ cat /proc/cmdline
write-through with write allocation은 논리적으로 불가능한 건가요?
당연히 논리적으로 충분히 가능합니다.
write-through에서 write-allocation을 사용할 때의 장단점은 다음과 같습니다.
장점: write 후 read 시 캐시를 사용하므로 빨라집니다.
단점: write 후 read를 하지 않는 경우 eviction이 낭비됩니다. 즉 사용할 캐시 영역이 줄어드는 단점이 발생합니다.
안녕하세요 설명 감사합니다. Os(리눅스)에서 write-through나 write-back설정을 사용자가 직접 할수있는 방법이 있을까요
리눅스는 메모리에 대한 기본 매핑으로 가장 빠른 방법을 사용하고 Armv6에서는 Write-Back, Armv7에서는 Write-Back Write-Allocation을 기본으로 사용하고 있습니다. 디바이스에서 사용할 reserved 영역들을 위해 다른 종류의 매핑을 사용하기도 하는데 이 때에 사용하는 API로 ioremap()을 사용합니다. 참고: http://jake.dothome.co.kr/ioremap
답변감사합니다.
Write-back 방식 기본으로 설정이 되어있으면 write-through 방식으로 사용자가 변경할수있는 다른 방법이 있을까요(커널단에서의 설정변경이나 bios를 통한방법으로도 변경가능한지 궁금해서요)
Write-back 방식의경우 Dirty cache를 clean할때 io_wait를 발생시키는것같아서.. io_wait를 발생을 회피할수있는 write-through방식으로 app을 구동하고싶어서 문의를 드립니다.
application 마다 캐시 특성을 바꾸는 방법은 커널이 지원하지 않습니다.
예를 들어 abc 파일을 하나의 application에서 write back으로 매핑하여 사용하고,
두 번째 application에서 non cache로 매핑하여 사용하는 경우,
캐시 일관성 문제가 발생합니다.
따라서 일반 메모리는 한꺼번에 같은 방식의 메모리 캐시 타입으로 매핑해서 사용해야 합니다.
커널 메모리 전체를 일부러 다른 방식으로 매핑하려면 커널의 헤더 파일 일부를 수정하면 간단합니다.
다만 위에서 언급한 것처럼 특정 application에 대해 변경하려고 하면 그만한 문제점이 발생합니다.
DMA 디바이스에서는 특정 영역의 메모리에 대해 캐시 타입을 바꿔서 사용하기도 합니다.
물론 커널에서는 이 영역을 미리 reserve하여 일반 캐시를 사용하는 메모리 매핑을 하지 않았을 것이고 원하는 캐시 타입으로 매핑하여 사용할 수도 있습니다.
그것을 설명한 것이 ioremap() 함수였습니다.
자세한 설명 감사합니다.
App별로 설정을 다르게할수는없겠군요
그럼 커널 전체의 메모리를 write-through방식으로 변경을 해보려고하는데요 혹시 어떤 헤더파일을 확인하면 되는지 알수가 있을까요
그리고 DMA디바이스의 경우 어떤식으로 캐시타입을 변경하는지 궁금합니다. 변경하는 이유는 아직 메모리에 옮겨지지않은 캐시 내 정보를 DMA디바이스가 찾질못하기 때문인가요?
커널 파라메터에서 “cachepolicy=“을 추가하시고 부팅하시면 됩니다.
참고로 armV6 아키텍처의 default는 writeback이고, armV7 아키텍처의 default는 writealloc입니다. (write-back & write-alloc)
DMA 디바이스는 cpu가 특정 메모리를 캐시해서 사용하는지 안하는지 모릅니다. 그냥 메모리에 읽고 쓰고만 합니다.
따라서 cpu가 DMA 디바이스가 사용하는 영역을 캐시하지 않는 경우 캐시 불일치등의 트러블이 발생하지 않습니다. 다만 캐시를 사용하지 않아 매우 느립니다.
성능이 중요 시 되는 장치라고 판단되면 DMA 디바이스가 사용하는 메모리도 캐시를 적용해야 cpu에서 해당 메모리에 대한 접근이 빈번할 경우 성능을 기대할 수 있습니다. 다만 캐시된 정보는 DMA 디바이스가 인지하지 못하므로 cpu와 dma 디바이스간의 읽고 쓰는 처리 방법에 대해 서로 약속을 해야 합니다.
cpu가 기록한 정보들은 캐시를 clean 한 후에만 디바이스가 읽어가게 한다든지 소프트웨어 적인 기법으로 캐시 일관성 문제를 해결해야합니다.
cache coherent & dma 등으로 검색하시면 정확한 이유 등을 알아보실 수 있을 것입니다. 다만 매우 복잡합니다.
궁금한 부분들을 쉽게 설명해주셔서 감사합니다.
알려주신 방법으로 메모리 사용방식을 변경해보려고 하는데요 변경 후에 적용이 정상정으로 되어있는지 확인할수있는 부분이 있나요?
제가한 방법은 sysctl. conf파일에 cachepolicy=writethrough를 추가하고 서버리붓을 하는방법이었는데요. 리붓후에 확인해보니 여전히 writeback방식을 사용하고 있었습니다. 커널로그에서는 cachepolicy관련 정보가 없는것 같은데 다른부분에서 적용 확인이 가능한곳이 있을까요
커널 파라메터 또는 부트 파라메터라고도 불리는데 이것 들을 입력하는 곳은 총 3군데 중 하나를 고쳐야 합니다.
1) uboot 설정
– 정확히 기억이 나지 않습니다.
2) 커널 설정
– menuconfig에서 설정
3) 디바이스 트리를 사용하는 경우 디바이스 트리에 설정
– /chosen 노드의 bootargs 속성으로 설정할 수 있습니다.
관련 커널 컴파일 옵션: CONFIG_CMDLINE, CONFIG_CMDLINE_FORCE
부팅 후 커널 파라메터가 제대로 입력되었었는지 여부를 확인하려면 다음과 같이합니다.
$ cat /proc/cmdline