I/O Scheduler Patch
<변경사항 이력>
12월 16일 오전 11시 40분 : 복구시 부팅 한번으로 복구되도록 수정
-> 적용 및 복구시, 어플을 모두 닫으시고, 미디어스케팅이 진행 중일 때는 적용하지 마시기 바랍니다. (무한강종의 원인이 될수있습니다)
-> 하기 본문의 <유의사항>은 반드시 숙지해주세요. 문제발생 시 책임은 사용자본인에게 있다고 적어놓았지만 재 마음이 편치 못하네요.
12월 15일 저녁 10시 : 주요영역만 적용하는 패치로 복귀 / 외장 SD카드 장착유무에 따라 자동 적용 (외장 패치를 하는것이 아님) -> 추가영역 및 모든영역 적용시, 정상적용은 되지만 복구후 문제 발생(강종) -> 여러가지 방안, 영역들을 적용하여 테스트했지만 결국 문제 발생 (아..여기서 엄청난 양의 if문과 파일들을 작성했음 ㅡㅡ;;; , ) -> 각각 적용방법들에 대한 문제의 원인은 90%이상 규명이 가능하지만, 나머지 10%를 확실히 파악하지 못했으므로, 주요영역만 적용함 -> 주요영역만 적용해도 사실 본 패치의 100%에 가까운 효용성을 확보함 -> 외장 SD카드의 장착 유무에 따라 자동으로 패치가 적용되는 스크립트로 수정함. -> 혼자 비밀리에 추가적인 부분을을 적용할 계획입니다. 때가 되면야 오픈하겠죠~ ^^ ps1. 사실 시간이 많이 부족해요.... 아시는 분은 아시겠지만, 한두가지이상의 환경이나 방안이 추가되면 스크립트의 if문이나 스크립트 구조를 짜는게 정말 복잡해집니다 ps2. 10% 에러의 문제를 확인하기 위해서는 순정+루팅상태에서 분석해봐야하는데, 저도 회사원인지라 현재 커널이나 기타 각종 패치류를 사용하고 있어서 잡기가 쉽지는 않습니다. 추후에 순정+루팅상태에서 적용하여 문제의 원인을 확인해보겠습니다. 12월 14일 오전 12시 50분 : 주요영역만 적용 / 모든영역 패치부분은 내림 -> 주요영역부분만 적용하는 스크립트를 다시 올렸으니, 모든영역 수정본이 나오기전까지는 본파일인 주요영역만 적용하시기 바랍니다. -> 모든 영역적용부분 패치는 다시 올릴때까지 적용하지 마시기 바랍니다. 겔러리 여실때 등 이미지를 제대로 불러오지 못합니다. -> 사실 이부분때문에 모든영역을 적용할까 고민을 했었는데, 예상했던것처럼 이것은 무리가 있군요. 예상되는 곳이 있으므로, 이부분은 제가 시간을 갖고 테스트를 한후 완료되면 모든영역부분의 패치를 다시 올리겠습니다. 12월 14일 저녁 12시 10분 : 모든 영역 적용 / 주요부분 적용 선택 12월 14일 저녁 8시경 : 1차 주요부분적용 이 패치는 스크립트 명령을 통한 패치법입니다. - 겔럭시S의 각 해당 block들의 I/O스케쥴러 설정값을 변경하여 I/O latency time을 줄여주어 그 성능향상을 기함에 있습니다. - init.d 지원되는 커널에서만 가능하던 부분을, 부팅시 스크립트를 실행되게하여 한번 적용하면 복구하기전까지는 재부팅을 해도 재적용할 필요없이 해당 패치를 무중단으로 사용할수 있게 하였습니다. - 유의사항만 잘 읽어보시면 절대 무한부팅되거나 문제발생하지 않습니다. 아울러, 본 패치를 무단으로 배포하지 말아주시기 바라며, 필요 시 "맛클 | 이카루스" 로 그 출처를 밝혀주시고, 본 사이트의 링크를 통해 사용해주시기 바랍니다. (대단한것은 아니지만, 그래도 그 출처는 분명 맛클입니다) 정보출처<맛클 자양님의 글 원문> : http://matcl.com/s/?mid=freeboard&category=9003&document_srl=653073 <자양님 블로그> : http://blog.naver.com/dowkim10/120119483848 를 참조하였습니다. 아!그리고 EcaDENt 님의 관심도 한몫 거들어주셨습니다. <적용효과> - I/O Delay 를 줄여주어 성능 향상 - 보다 부드러움(사용해보신 분들의 말에 의하면 Nilfs2적용했을때처럼 부드럽다고합니다) 1. 반드시 루팅을 먼저 하시기 바랍니다. 2. 외장패치를 하신분들은 외장패치를 해제하시기 전에는 사용하지 마시기 바랍니다.. 3. 새로운 패치적용전에는 반드시 현재 패치를 복원후에 새패치를 적용하는 것이 기본입니다. 본패치적용후 재적용하실때에도 반드시 본패치 해제후 다시 재적용하는 해야 하는 것이고, 외장패치역시 ,본 패치적용 후에 복원하지 않고 외장패치하시면 안됩니다. 반드시 복구하시고 외장패치 적용하시기 바랍니다. 4. 겔스에 busybox가 다운 및 install되어 있어야 합니다. 없으신 분들은 마켙에서 검색하셔서 설치하신후 실행하시어 install 하신후 패치적용해주세요. 5. 부두, 테그라크 등의 패치를 사용하신분들 모두 가능합니다. 6. 사용중이신 모든 어플들을 닫고 적용하시기 바랍니다. 물론 미디어스캐닝도 모두 완료된 이후에 적용하시기 바랍니다. 7. 적용후 문제발생시 그 책임은 분명 본인에게 있습니다. 단, 본 유의사항과, 본문내용을 잘 읽으신분들은 문제발생할 요지가 거의 없습니다. <패치적용 영역> 1. 주요 영역 mmcblk0 (/data영역과 /sdcard 모두 포함) mmcblk1 (외장 SD카드 모두 포함) stl9 (/system영역 포함) stl10 (dbdata 영역 포함) stl11( /cache 영역 포함) <적용방법> 2. icarus.sh 와 icarus폴더를 겔스에 복사 - 겔스와 PC연결시 보이는 루트디렉토리를 의미함 3. 겔스와 PC를 연결하시고 adb를 실행 4. $표시 프롬프트에서 SU를 입력하여 슈퍼유저 권한 획득 5. # busybox sh /sdcard/icarus.sh 1 = Apply I/O Scheduler patch r1 = Recovery for I/O Scheduler patch x = exit : "1" 을 누르면 적용 부팅시 반드시 안드로보이 또는 해외판 로고등이 나와야 합니다. 7. 적용뮤무 확인방법은 cd /sys/block/stl10/queue cd /sys/block/stl11/queue cd /sys/block/mmcblk0/queue (외장SD카드 를 작착하신 분) cd /sys/block/mmcblk1/queue 을 실행하였을 때, 그 결과값이 하기와같에 [ ] 가 deadline 에 적용되어 나오면 정상적용된 것입니다. noop anticipatory [deadline] cfq 마찬가지로 복구하였을 경우, 로 나오면 정상적으로 복구가 된것입니다. **** 적용후 마음에 드시면 추천 눌러주시면 제작한 저도 마음 한켠이 흐믓할 것 같습니다 ^^ **** 문의사항은 맛클사이트를 이용하여 주시기 바랍니다. 감사합니다. <부연설명> I/O Scheduler 란? 보다 더 많은 내용이 아래 자양님의 글에 있으니 참조하시기 바랍니다. 파일에 대한 억세스(read,write)에 대한 지연과 리눅스에서 사용하는 IO 스케듈러와 밀접한 관련이 있다. http://www.wlug.org.nz/LinuxIoScheduler 일반적인 대부분의 리눅스 시스템(redhat, ubuntu)등은 CFQ를 사용하고 있다. 이는 CFQ가 하드 디스크를 사용하는 일반적인 환경에서 처리량 및 지연에 대해서 좋은 성능을 보여주고 있기 때문이다. (갤럭시s도 CFQ를 사용한다.) response time 또는 IO delay가 가장 작은 것은 스케듈러는 deadline 스케듈러이다. 하지만, 단점은로 IO에 대한 억세스가 더 많으므로 플래시 수명에는 더 안좋으며, 전체적인 성능은 좀 떨어진다.
먼저 이 패치는 "자양"님이 올려주신 정보를 참조하여 작성하였습니다. 자양님 좋은 정보 감사드립니다. 또 더 좋은 정보 부탁드립니다. ^^
<실행시의 유의 사항> - 물론 사전에 "백업"은 필수입니다.
외장 패치를 원하시는 분들을 위해, 동시에 적용이 가능하며, 금번 IO Scheduler의 성능향상이 검증되면,
동시적용 스크립트 적용은 금방 가능하므로, 그때 외장패치까지 동시에 적용되는 패치를 올려드리도록 하겠습니다.
2. 모든 영역
상기 4개 block들을 여러분이 테스트한 결과, 좋은 성능향상과 부드러움제공으로 인해 모든영역을 추가하였습니다.
mmcblk0, 1
tfsr0!c ~ 12
bml0!c ~ 12
stl1 ~ stl12
1. 압축파일을 다운받아 해제
- 아스트로로 확인할 경우 /mnt/sdcard 디렉토리를 의미함
- 루트익스플로러로 확인할 경우 /sdcard 디렉토리를 의미함.
adb shell 엔터
$ su (<- 사용중인 커널에 따라 곧바로 # 표시 되고 슈퍼유저 권한부여될수 있음, 그러면 아래 SU를 치지 않아도됩니다)
su (<- 폰 화면에서 superuser 어플에게 Allow 를 해주셨는지 확인, 안하시면 아래 프롬프트 #이 안 나옵니다)
실행
6. PC화면에 아래와같이 나오면 적용합니다.
-> 주영역의 I/O Scheduler 적용
-> mmcblk0, mmcblk1, stl9, stl10, stl11
2 = Apply All I/O Scheduler patch ( 모든 영역 패치를 올려드린후 실행하시면 나옵니다, 현재 올려드린 주영역 패치에서는 안나옵니다)
-> 모든 영역의 I/O Scheduler 적용
->mmcblk0~1, tfsr0!c~12, bml0!c~12, stl1~stl12
-> 복구
adb 실행
cd /sys/block/stl9/queue
cat scheduler
cat scheduler
cat scheduler
cat scheduler
cat scheduler
noop anticipatory deadline [cfq]
===============================================================
자양님의 글 을 가져왔습니다. (자양님의 오타까지도 고스란히 가져왔습니다. ^^;;;)
물론 가장 IO 딜레이에 영향을 미치는 것은 파일시스템 및 플래시 매체이긴 하지만, 그다음으로 보자면 IO 스케쥴러로 생각된다.
리눅스에서 선택할 수 있는 IO 스케쥴러는 다음의 4가지 중에 하나이다.
Noop
Anticipatory
Dedline
CFQ (completly Fair Queuing)
Noop은 단순하며 ssd장치의 수명과 연관한다면 좋을수 있으며, Anticipatory는 핀을 사용하는 하드 디스크에 적합할 수 있으나 IO 딜레이가 큰편이며, deadline은 프로세서의 IO요청에 대해 특정 시간내에 처리를 하므로 starvation(굶는것)을 방지하고 response타이을 줄여 유저 인테페이스 반응을 좋게 한다.
하지만, 갤럭시s 같은 경우 처리량(performance/throuput)에 문제가 있는것은 아니다. 단지, response time이 늦는데 문제가 있다.
RFS 나 moviNAND 자체의 문제도 있지만, IO 스케듈러의 영향도 무시 못할 것이라 생각된다.
아래 링크의 벤치마크 테스트 자료를 보면 deadline 스크쥴러의 IO 딜레이가 가장작다.
http://lwn.net/Articles/113869/
