2012.11.06 01:36

ADB Sideload


What is ADB sideload?


ADB sideload is a new feature that was added to AOSP recovery in Jelly Bean.  ADB sideload is a different ADB mode that you can use to push and install a zip using one command from your computer.  Most likely ADB sideload won't be very useful for your average recovery user, but ADB sideload can be a huge time-saver for a ROM developer.

How do I use ADB sideload?


  1. Have a recovery installed on your device that supports ADB sideload like iCaRuS SpeedMod CWM6.0.1.5 or higher
  2. Have newer ADB binaries installed on your computer.  If it's been a while since you installed ADB on your computer, you may need to get the latest ADB binaries in platform-tools from the Android SDK.  You will need version 1.0.29 or higher.  You can find your current version by typing "adb version" at the command line.
  3. Set the device into ADB sideload mode. In iCaRuS SpeedMod CWM, you do this by  choosing  "Install zip from Sideload"option.
  4. From the command line, type adb sideload /path/to/rom.zip

The file will be copied to your device to whatever the current storage location is that you have selected in the mount page.  It will always be placed in the root of that storage location and named sideload.zip (e.g. /sdcard/sideload.zip) and it will automatically delete / overwrite any existing sideload.zip you may have on your device.  As soon as the file is copied to your device, it will automatically be installed.  When the install is finished you will be presented with a reboot system button so that you can reboot to test your zip.


Note that sideload mode is a separate ADB mode. While in sideload mode, regular ADB commands will not work. Once the zip has been copied to the device and the install starts (or if you hit the cancel button) regular ADB mode will resume.

저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

ADB Sideload  (10) 2012.11.06
Smartass V2 CPUfreq governor  (17) 2011.09.29
SmartAss Governor  (7) 2011.07.17
Dalvik-Cache  (1) 2011.04.05
RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
Trackback 0 Comment 10
  1. ans2744 2012.11.06 19:19 신고 address edit & del reply

    잘보고 갑니다.
    SKT노트2에 해외판노트2cwm6.0.1.5올려봣더니 벽돌되네요ㅎㅎ;
    노트2 이카루스스피드모드 기대해봅니다!

  2. Isabel Marant 2012.11.13 11:25 신고 address edit & del reply

    것들을 뒤 the teacher only was responsible for teaching us singing regardless of whether you performed or didn 't sing. Eventually, a lesson was through. Exactly what didn 't take heed to or even what not to be blind to discover. However the tutor is greatly distinct. She let us know rhythm and tune. To sing once again, immediately after is easier to s sadfwereqwrtq http://www.styleshoemall.com/categories/Isabel-Marant/

  3. Jimmy Choo 2012.11.13 12:39 신고 address edit & del reply

    것들을 뒤 the teacher only was responsible for teaching us singing regardless of whether you performed or didn 't sing. Eventually, a lesson was through. Exactly what didn 't take heed to or even what not to be blind to discover. However the tutor is greatly distinct. She let us know rhythm and tune. To sing once again, immediately after is easier to s sadfwereqwrtq http://www.styleshoemall.com/categories/Jimmy-Choo/

  4. Tod's 2012.12.04 11:07 신고 address edit & del reply

    신발 주변의 고체 고무 outsole는 아름다운 꽃 생기고 이전의 어떤 르브론 신발 한 후 다른 서클, 사용하여 패턴을 가지고 있습 qweeqwtretytry

  5. Miu Miu Boots 2012.12.04 11:58 신고 address edit & del reply

    것들을 뒤 the teacher only was responsible for teaching us singing regardless of whether you performed or didn 't sing. Eventually, a lesson was through. Exactly what didn 't take heed to or even what not to be blind to disco qweeqwtretytry

  6. Miu Miu Sneakers 2012.12.05 11:15 신고 address edit & del reply

    여러분 정말로 단지 자신의 다양한 포함의 가장 경제적 거의 모든 적절한 에어 조던 신발 중 하나를 찾을 수보다 한 시간보다 구매에 양해를 개발 않습니다. 이 항상 문제는 고가의 스타일을 끌어 들이고 의심 할 여지없이 당신의 크기 거의 다 qweeqwtretytry

  7. Miu Miu Boots 2012.12.15 10:42 신고 address edit & del reply

    여러분 정말로 단지 자신의 다양한 포함의 가장 경제적 거의 모든 적절한 에어 조던 신발 중 하나를 찾을 수보다 한 시간보다 구매에 양해를 개발 않습니다. 이 항상 문제는 고가의 스타일을 끌어 들이고 의심 할 여지없이 당신의 크기 거의 다 ewrqertyryrty

  8. Miu-Miu-Sneakers 2012.12.15 11:16 신고 address edit & del reply

    여러분 정말로 단지 자신의 다양한 포함의 가장 경제적 거의 모든 적절한 에어 조던 신발 중 하나를 찾을 수보다 한 시간보다 구매 ewrqertyryrty

  9. moncler 2013.01.05 17:07 신고 address edit & del reply

    Le bilan de l'attentat commis le soir du Nouvel An devant une église copte d'Alexandries'est alourdi à 23 morts, http://www.moncleroutletespain.com/ moncler chaquetas, rapporte mardi l'agence de presse égyptienne Mena, http://www.moncleroutletespain.com/ http://www.moncleroutletespain.com/.Le No, http://www.moncleroutletespain.com/ moncler españa?l copte, http://www.moncleroutletespain.com/ moncler online, célébré jeudi, http://www.moncleroutletespain.com/ moncler, sera encadré de nombreuses mesures de sécurité, http://www.moncleroutletespain.com/ moncler outlet.Related articles:


    http://oyeeee.tistory.com/9 http://oyeeee.tistory.com/9

    http://sofistory.tistory.com/72 http://sofistory.tistory.com/72

  10. SMS d 2013.01.07 15:26 신고 address edit & del reply

    이밑에분들뭐라고말하시는건지;;

2011.09.29 16:02

Smartass V2 CPUfreq governor




SmartassV2
---------------

The CPUfreq governor "smartassV2", like other governors, aims to balance
performance vs battery life by using low frequencies when load is low and
ramping the frequency when necessary, fast enough to ensure responsiveness.

The implementation of the governor is roughtly based on the idea of interactive.
The idle loop is used to track when the CPU has idle cycles. The idle loop will
set a relatively high rate timer to sample the load when appropriate, the timer
will measure the load since it was set and schedule a work queue task to do the
actual frequency change when necessary.

The most important tunable is the "ideal" frequency: this governor will aim
for this frequency, in the sense that it will ramp towards this frequency much
more aggresively than beyond it - both when ramping up from below this frequency
and when ramping down from above this frequency. Still, note, that when load is
low enough the governor should choose the lowest available frequency regardless
of the ideal frequency and similarly when load is consistently high enough the
highest available frequency will be used.

Smartass also tracks the state of the screen, and when screen is off (a.k.a
sleep or suspended in the terms of this governor) a different ideal frequency
is used. This is the only difference between the screen on and screen off
states. Proper tuning of the awake_ideal_freq and sleep_ideal_freq should
allow both high responsiveness when screen is on and utilizing the low
frequency range when load is low, especially when screen is off.

Finally, smartass is a highly customizable governor with almost everything
tweakable through the sysfs. For a detailed explaination of each tunable,
please see the inline comments at the begging of the code (smartass2.c).

저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

ADB Sideload  (10) 2012.11.06
Smartass V2 CPUfreq governor  (17) 2011.09.29
SmartAss Governor  (7) 2011.07.17
Dalvik-Cache  (1) 2011.04.05
RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
Trackback 0 Comment 17
  1. 갤s 2011.09.29 17:46 신고 address edit & del reply

    앗 새로운 가버너의 등장인가...

  2. 와양쿨릿 2011.09.29 22:26 신고 address edit & del reply

    앗.. 2등이다.. 기대되네요ㅎ

  3. Jordan Spizikes 2012.01.05 11:51 신고 address edit & del reply

    적당한 쌍을 찾는 일이 정말 많은 시간과 노력을 수반하지 않습니다. 이것에 비추어 볼 때, 발에 가장 적합한 스포츠 신발을 선택하기 위해 고려해야 할 4 단계가 있습니다.

  4. agneepath review 2012.01.22 23:33 신고 address edit & del reply

    적당한 쌍을 찾는 일이 정말 많은 시간과 노력을 수반하지 않습니다. 이것

  5. Online Listings 2012.01.23 19:31 신고 address edit & del reply

    伟大的网站!我喜欢它!!会回来以后多读一些。我书签您的供稿。

  6. Nike Foamposites 2012.03.14 17:01 신고 address edit & del reply

    오직 당신에게 도움이 될 수있는 무언가를 - 나이키는 지속적으로 그들의 실행 신발을 개발하고 향상하기위한 새로운 방법을 찾고 있습니다.
    http://www.nikeairfoamposites.net/ Nike Air Foamposites
    http://www.nikeairfoamposites.net/ Nike Foamposite Shoes
    http://www.nikeairfoamposites.net/ Nike Foamposites

  7. Website 2012.03.26 06:14 신고 address edit & del reply

    인생 무척이나아름다웠다.

  8. Galaxy Foamposites 2012.04.09 17:15 신고 address edit & del reply

    나이키 하나는 Hardaway는 1997 년 누볐어하는 서명 스니커즈 중 하나입니다. 기술은 발이 놀이의 더위를 통해 개인의 발에 곰팡이 수 있도록 폴리 우레탄을 활용합니다. 이 신발, 페니의 서명 운동화 라인처럼 운동화 세계에 지속적인 인쇄물을두고하고 있습니다.

    http://www.airfoampositesale.com/

  9. Galaxy Foamposites 2012.04.09 17:28 신고 address edit & del reply

    나이키 하나는 Hardaway는 1997 년 누볐어하는 서명 스니커즈 중 하나입니다. 기술은 발이 놀이의 더위를 통해 개인의 발에 곰팡이 수 있도록 폴리 우레탄을 활용합니다. 이 신발, 페니의 서명 운동화 라인처럼 운동화 세계에 지속적인 인쇄물을두고하고 있습니다.

    http://www.airfoampositesale.com/

  10. Jordan 1 KO 2012.05.29 15:59 신고 address edit & del reply

    덜컹 도로에서 시작된 브랜드 신발 산업에 가장 큰 영향 중 하나를 만드는 성장했으며이 날 때까지 계속 착용하고 자신의 외모를 칭찬했다.
    http://www.airjordan1ko.com/ Jordan 1 KO
    http://www.airjordan1ko.com/ Jordan Retro 1
    http://www.airjordan1ko.com/ Jordan 1

  11. Jordan 4 military blue 2012.06.08 11:52 신고 address edit & del reply

    트랙션은 그 나무에서 재생할 특히 이후 거의 피할 수있을 것입니다. 신발 앞발과 뒤꿈치 주위 덜 차려면 발목 트위스트를 우승 확률은 거의 100 %입니다. 조던 신발들은 발목 염좌를 방지이 방법을 사용하여, 앞발과 실제 뒤꿈치 모두에 큰 견인을 포함합니다. http://www.jordanretro4militaryblue.net

  12. Air Yeezy 2 2012.06.08 11:56 신고 address edit & del reply

    나이키 에어 Yeezy는 나이키 주식 회사 지난 시즌을 통해 발표된 독특한 신발이 될 수 있습니다. 우리는 구체적으로 한사람 한사람이 아이 티어 제로 나이키 기록을 제공하고 단지 결국 연간 사용하는 동안 아마도 가장 원하는 신발이 있었다 생각하고 있었다. http://www.yeezy2.net

  13. Air Yeezy 2 2012.07.11 12:19 신고 address edit & del reply

    당신은 나이키에 가까운 가까운 시계를 유지한다면, 당신은 아마 스포츠의 대기업 (멋진 제품을 통해 '오래된 제품'다시 출시와 더불어 시작) 발표 보유하고있다는 사실 알고 새로운 흥미로운 제품으로 불리는 우연히 것을 수많은 최근 과거 이내. http://www.airyeezy2online2012.com

  14. Louboutin UK 2012.08.07 11:43 신고 address edit & del reply

    블랙 스웨이드의 Louboutin 만들 관음증 하단 매끈한 스타일은 펌프가 판매 즉시 고전이 좋다고. 그들은 아름다운과 함께 우아! 어떤 식으로든 매력적인 패턴 byChristian Louboutin 판매에서 찾고, 그것은 그들이 유명 인사, 충성스러운 팬들 번호 빅토리아 베컴, 안젤리나 줄리, 마리아와 관련된 전세계 O 롤 주위에 화려한 여성에 관한 세련된 선택이 될 이유를 찾기 쉽습니다. http://www.louboutinukbuy.co.uk

  15. Jordan 6/7 Gold Pack 2012.08.07 11:46 신고 address edit & del reply

    또한 과거에 보고된 실제 Retros가 추가로있다 레트로-pluses 어느 사실에도 불구하고, 보통 다시 도입 진품입니다 그 전체 시스템 스타일의 내부에 만들어 업데이 트와. 이러한 모델은 그들이 매우 진정으로 비싼 만들 수있는 약간의 수량, 생산 수 있습니다. http://www.jordan67goldpack.net

  16. Foamposites For Sale 2012.10.15 10:43 신고 address edit & del reply

    이 고급 나일론 얌전 히 가만히는 운동화에 아늑한 느낌이 만드는 땀을 할 수 있습니다. 이 코팅은 특정 부분 내부가 안심하고 일치시킬 수 있도록하는 데 도움이됩니다. 내 생각은, 어떻게 다리와 쉽게 서비스의 변화 때문에 그 신발의 목 부분에 뒤꿈치를 즐길 수 있습니다. http://www.foampositesstore.com

  17. Over-Ear Headphones 2012.10.23 10:31 신고 address edit & del reply

    이 고급 나일론 얌 engraving do the work is concluded be ghaarias, the enameling do the job is done be the enameler, the goldsmith looks following the gold or kundan get the function completed and eventually stone setters do operate of just surroundings the dear or semi-precious stone inside the holes inside the jewellery. hhjjkkllppuyiiuyasa http://greatmonsterbeats.com/categories/Monster-Turbine/

2011.07.17 13:49

SmartAss Governor


Smartass CPU Frequency Governor
- Interactive 기반의 Governor ( dynamic cpufreq policy governor)
- Interactive 보다 조금더 빠른 Response
- Interactive 보다 Lower Frequency에 있는 시간이 더 많음 -> 배터리효율이 더 좋음을 의미함
- Interactive 보다 Mobile 단말장치에 더 적합함
- Author는 Erasmux 이며, 주요한 부분의 소스코드를 모두 수정하여, SpeedMod Kernel에 맞게 build하였으며,
  SpeedMod Kernel에 맞게 파라미터값들을 최적화조합으로 수정함.
- SetCpu 의 Advanced 탭에서는 Smartass gov를 검색하지 못하니 이상하다고 생각마시고 사용하세요




SMARTASS GOVERNOR - is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works - by taking over the idle loop - is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the "old" minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 245Mhz (or if your min frequency is higher than 245 - why?! - it will cap it to your min frequency). Lets take for example the 600/245 kernel, it will sleep at 245. No need for sleep profiles any more!
저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

ADB Sideload  (10) 2012.11.06
Smartass V2 CPUfreq governor  (17) 2011.09.29
SmartAss Governor  (7) 2011.07.17
Dalvik-Cache  (1) 2011.04.05
RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
Trackback 0 Comment 7
  1. 뽀물 2011.07.17 13:52 신고 address edit & del reply

    영리한 똥꼬 좋아요

    • 준규앙마 2011.07.17 15:35 신고 address edit & del

      똥꼬는 애스홀 아닌가요^^

  2. 대구경신 2011.07.17 15:38 신고 address edit & del reply

    그냥.. 좋다는거겟지..?

  3. iCaRuS™ 2011.07.17 16:57 신고 address edit & del reply

    ㅎㅎ. 그냥 좋다는 거죠 뭐~ ^^

  4. Nevermore 2011.07.18 17:45 신고 address edit & del reply

    Interactive와 InteractiveX에 있던 "갑자기 폰이 마구 느려져서, 현재 CPU load가 지속되는 내내 계속 느려지는" 버그가 없어서 좋습니다^^ 위의 두 governor는 하던 작업을 완전히 멈추고 몇초간 폰을 idle 상태로 놔두지 않으면 저 버그가 풀리지 않고 폰이 계~속 느려지곤 했었죠.

    저같은 경우엔 Interactive와 InteractiveX를 쓸 때, 홈스크린을 빠르게 넘기다 갑자기 폰이 느려질 때가 있었습니다. 그럴때면 폰 사용을 아예 멈추고 폰을 몇 초 내버려두지 않으면 폰이 너무 느려져서 사용 불가능해지곤 합니다.

  5. ueproject 2011.09.26 18:50 신고 address edit & del reply

    저같은 경우에는 대기 시간이 많고, 띄엄 띄엄 잠깐씩 사용하다 제대로 사용할때 부와아앙 하고 부하 많이먹는 어플리케이션(게임, 동영상, 웹서핑)을 하는 편인데 그런 경우 그냥 on-demand가 나을까요?
    요놈이 잠깐 잠깐 화면 킬때도 800~1200으로 올려버리고, 화면 켜있을때는 필요 이상으로 cpu를 올리고 놀아서 끊김이 정말 거의 없어서 좋기는 한데 조루증이 증폭되는군요;

2011.04.05 15:21

Dalvik-Cache

SpeedMod커널의 Wipe Dalvik-cache 가 어떤것인지를 질문하시는 분들이 있어서 자료를 올립니다.

Dalvik-cache는 간단하게 말씀드리면, java가상머신으로 안드로이드 어플들을 빨리 수행되도록 최적화 분석정보를 저장한 Cache영역을 의미합니다. Wipe Dalvik-cahce 란 기능은 Jav 가상머신의 캐시영역을 깨끗하게 지워주는 것입니다.
이영역은, 어플들이 실행될때 다시 저장되는 영역이며, Wipe Dalvik-cache를 하고 부팅하면, 첫 부팅시간이 오래걸리므로 당황하지마시기 바랍니다.


출처 : http://sink772.egloos.com/3490667, 씽그페드님 블로그
출처 : http://blog.vizpei.kr/63464875, 비즈페이님블로그

Android 플랫폼의 핵심은 바로 Dalvik VM이라 불리우는 런타임 환경이다.  애플리케이션 개발은 Java 언어를 사용하면서 왜 런타임 환경은 Java VM이 아닌 또다른 VM를 채용했을까라는 것이 이슈인데, Stefano Mazzocchi의 블로그 글에서 이에 대한 해답을 찾을 수 있다.  결론만 말하자면 SUN과의 라이센스 문제 때문인데, 작년말에 SUN이 PhoneME라는 이름으로 Java ME 관련 코드를 오픈 소스화하긴 했지만, 실제로 Java VM을 핸드셋에 탑재하기 위해서는 SUN에 라이센스 비용을 꼬박꼬박 물어야 한다.  즉 생색은 있는 대로 다 내면서 실속 또한 챙기는 이중 전략인 셈인데, 이를 비껴가기 위해서 구글은 Dalvik VM이라는 카드를 꺼내든 것이다.  애플리케이션 개발 환경은 Java SE 관련이므로 그 유명한 Classpath 예외조항에 따라 라이센스 문제를 피할 수 있지만, Java ME 쪽은 예외조항이 없으므로 Java VM을 배제하고 또다른 VM을 탑재하는 식으로 처리를 한 것이다.  구글맵 등 이미 Java 언어 기반으로 모바일 애플리케이션을 배포하던 구글로서는 기존의 인프라를 그대로 살리고 싶어했을 것이고, 또 거의 모든 소스를 오픈하여 자유롭게 사용할 수 있도록 배포하려던 정책도 SUN과의 라이센스 문제 때문에 포기할 수는 없었을 것이다.


Android SDK로는 Java 소스를 Dalvik bytecode로 직접 컴파일 할 수 없습니다.

처음에 정식 Java 컴파일러를 사용하여 정식 Java bytecode를 생성한 뒤에, Dalvik bytecode로 변환하도록 Android SDK에 dx라는 툴을 포함시켜 두었습니다. 여러개의 .class파일들을 dx툴을 사용하여 하나의 .dex파일로 변환하는 것이죠. 이때 중요한 것은 .dex파일로 변환할 때에 Java bytecode를 Dalvik VM에서 사용하는 bytecode로 변환하는데에 있습니다. 여기서 Java VM과의 상관은 끊어지게 되는 것이죠. 보통 같은 .class파일을 가지고 .jar파일로 변환할 때보다 .dex파일로 변환하면 크기가 조금 줄어든다고 합니다. 여튼 중요한건 'Android는 Java VM을 사용하지 않는다.' 라는 사실입니다.

 

[SUN의 라이센스를 피해서]

구글의 입장에서는 Java VM을 사용해서는 안되는 상황이 만들어 져버렸습니다. 바로 Java ME의 라이센스 정책 때문입니다.Java는 GPLv2하에 배포가 되었던 오픈소스였습니다. 뭐, 거기까지는 좋습니다. 하지만 Java ME에서 그 '예외'가 발생 해버렸죠.핸드셋에 Java VM을 탑재하기 위해서는 SUN에게 라이센스 비용을 지불해야 합니다.

역시 Java VM을 사용하지 않는것 밖에는 방법이 없던것 같군요...

 
[Using Java SE]

위에서 말씀드렸듯이 dx툴을 사용하여 Java 플랫폼 어플리케이션을 Dalvik Excutable(.dex)로 변환 할 수 있습니다.

이때 사용되는 Java는 Java ME가 아니라 Java SE입니다. 정식 Java SE를 사용하여 .class파일을 생성 하고 난 뒤에 .dex파일로 변환하는 과정을 통해 Java ME는 전혀 사용하지 않고, SUN의 라이센스 정책을 피해 갈 수 있었던 것이었습니다.

 

[Dalvik VM의 특징]

Dalvik VM은 Java VM과는 조금 다른 물건입니다.일단 Dalvik VM은 Dan Bornstein이라는 분이 제작을 했는데, 그 분의 선조들이 살던곳이 Dalvik이라는 곳이라네요.

위키피디아에 보면 Java VM은 Stack-Based Architecture인데에 비해 Dalvik VM은 Register-Based Architecture라고 설명 되어 있는 걸로 봐서 왠지 Dalvik VM이 작은 디바이스 쪽에 좀더 최적화 되었다는 느낌을 줍니다. 실제로 DalvikVM.com에도 Low Memory에 최적화 되었다고 소개가 되고 있습니다.

Dalvik VM의 Constant pool은 32bit 인덱싱만 하도록 변경이 되었다느니, Just-In-Time 컴파일러가 아니라느니 등등의 특징들도 있습니다만,  중요한 부분은 여러개의 VM Instance를 실행 시킬 수 있도록 디자인 되어 있으며,Linux Kernel을 사용하기 때문에 프로세스 독립성을 가지고, Linux의 메모리 관리스레딩을 사용 할 수 있다는 점 입니다.

저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

Smartass V2 CPUfreq governor  (17) 2011.09.29
SmartAss Governor  (7) 2011.07.17
Dalvik-Cache  (1) 2011.04.05
RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
Trackback 0 Comment 1
  1. nanu 2011.07.24 21:26 신고 address edit & del reply

    감사합니다 잘읽었습니다
    완전히 이해하진 못했지만 대충 이런것이다는걸 알게되었네요^^

2011.03.31 23:00

RAMZSWAP


메모리의 가용성확보를 위해, /dev/block/ramzswap0에 메모리를 swap.

num_devices=1 disksize_kb=51200  옵션적용. ( 50M)


ramzswap 테스트 커널을 오딘으로 덮은후,
/system/etc/icarus/ramzswap 디렉토리생성후 재부팅하면, 적용됨

[주의사항]
ramzswap사용시, /data의 loopdevice 옵션을 ramzswap와 동시에 사용하지 마세요.
또한 bind data_to_dbdata 를 ramzswap과 동시에 사용하지마세요.

<적용확인방법>

adb shell 에서,
$ ls /dev/block 또는
$ ls /dev/block/ramzswap0
해서 ramzswap0이 나오면 성공

루트익스플로러로에서, /sys/block/ramzswap0 이 있으면 성공.


<ramzswap 상태확인>
adb shell또는 터미널에서, 다음 2가지방법중 하나를 실행하여 메모리swap 상태 확인

$ free
              total         used         free       shared      buffers
Mem:       357480       331892        25588            0         8648
Swap:        51192         4460        46732
Total:       408672       336352        72320


$ cat /proc/meminfo
MemTotal:         357480 kB
MemFree:           28508 kB
Buffers:            8624 kB
Cached:            77936 kB
SwapCached:         2980 kB
Active:           118436 kB
Inactive:         140084 kB
Active(anon):      78184 kB
Inactive(anon):    99808 kB
Active(file):      40252 kB
Inactive(file):    40276 kB
Unevictable:        5672 kB
Mlocked:               0 kB
SwapTotal:         51192 kB
SwapFree:          46732 kB
Dirty:                28 kB
Writeback:             0 kB
AnonPages:        176448 kB
Mapped:            59520 kB
Shmem:               360 kB
Slab:              13888 kB
SReclaimable:       4816 kB
SUnreclaim:         9072 kB
KernelStack:        4032 kB
PageTables:        15840 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      229932 kB
Committed_AS:    8677504 kB
VmallocTotal:     319488 kB
VmallocUsed:       74400 kB
VmallocChunk:     202756 kB



<ramzswap 해제방법>

방법1 : /system/etc/icarus/ramzswap 디렉토리삭제후 재부팅

방법2 : adbshell 에서,
busybox swapoff /dev/block/ramzswap0
busybox rmmod ramzswap
재부팅필요없음.



<ramzswap 재 적용 방법>

방법1 : /system/etc/icarus/ramzswap 디렉토리 생성 후 재부팅

방법2 : adbshell 에서,
busybox insmod /icarus/lib/modules/ramzswap.ko num_devices=1 disksize_kb=51200
busybox swapon /dev/block/ramzswap0
재부팅필요없음

























출처 : http://code.google.com/p/compcache/wiki/CompilingAndUsingNew


CompilingAndUsingNew  
Compiling and Using ramzswap (0.6 or newer)
Phase-Deploy, Featured
Updated Jan 24, 2010 by nitingupta910
  • NOTE
    • It requires kernel version 2.6.28 or higher.
    • Kernel 2.6.33 will have partial support for compcache. So, if you are using this kernel, please do not use in-tree compcache version. Use compcache version as available from this project's download page. Kernel 2.6.34 will (hopefully!) will have complete support.

Introduction

compcache-0.6 brings some new features which require some changes to the way you use it. Some of the new features include:

  • Support for file as backing swap. Earlier versions (0.5.x) only allow using a block device as backing swap.
  • Support for multiple /dev/ramzswapX devices.
  • New rzscontrol utility to manage various ramzswap devices: setting parameters, initializing, resetting, stats collection.
  • Support for swap free notify callback. This will give ramzswap a callback as soon as a swap page becomes free -- stale data, no more!
    • A separate patch will be included that adds hooks in kernel swap path to enable this feature.
    • Rest of ramzswap will remain as separate modules. It will be usable on kernels with or without this patch. Of course, without patch, ramzswap will have this feature disabled.

Its known to work on x86, x86_64 and ARM.

Details

Compiling

  • make: This will compile all modules against your kernel
  • make doc: This will compile rzscontrol manual page: sub-projects/rzscontrol/man/rzscontrol.1
  • Optional (HIGHLY RECOMMENDED):
    • Apply patch found in compcache/patches/ directory and just compile the kernel as usual -- currently, patch is against 2.6.33 but it should apply to slightly older kernels too. This will enable 'swap free notify' feature. This allows kernel to send callback to ramzswap as soon as a swap slot becomes free. So, we can immediately free memory allocated for this page, eliminating any stale data in (compressed) memory.
    • Uncomment '#define CONFIG_SWAP_FREE_NOTIFY' in compcache/compat.h before compiling compcache against this patched kernel. Otherwise, this swap notify callback will not be used.

NOTE: ramzswap will work on kernels with or without this patch. Of course, this feature will be disabled if compiled against kernel without this patch.

Using

Above compilation gives following modules:

  • ramzswap.ko (virtual block device driver)
  • rzscontrol (userspace utility to setup individual ramzswap devices)

Following shows a typical sequence of steps for using ramzswap.

  • Load Modules:
# load dependency modules 
modprobe lzo_compress 
modprobe lzo_decompress
# example1: load ramzswap module 
insmod ramzswap
.ko num_devices=4

This creates 4 devices (/dev/ramzswap{0,1,2,3}) which are left uninitialized.

# example2: load ramzswap module and initialize the first device 
insmod ramzswap
.ko num_devices=4 disksize_kb=20480

This initializes first device (/dev/ramzswap0) with disksize of 20MB. Other 3 devices (/dev/ramzswap{1,2,3}) are left uninitialized.

# example3: load ramzswap module and initialize the first device 
insmod ramzswap
.ko backing_swap=/dev/sda2 memlimit_kb=20480

This initializes the first device with a backing swap and memlimit of 20MB. Here only one device is created (num_devices=1 by default). If memlimit_kb was absent, default value of 15% of RAM would have been used.

Initialization of first device directly from insmod parameters is useful for embedded systems where shipping an additional binary (rzscontrol) might not be desirable. However, without rzscontrol, you cannot reset and reconfigure devices without module reload. Viewing ramzswap statistics is also possible only through rzscontrol utility.

  • Initialize:
Use rzscontrol utility to configure and initialize individual ramzswap devices. Example:
rzscontrol /dev/ramzswap0 --init # uses default value of disksize_kb
See rzscontrol manpage for more details and examples.
  • Activate:
    swapon /dev/ramzswap2 # or any other initialized ramzswap device
  • Stats:
    rzscontrol /dev/ramzswap2 --stats
  • Deactivate:
    swapoff /dev/ramzswap2
  • Reset:
    rzscontrol /dev/ramzswap2 --reset
  • Unload Modules:
    rmmod ramzswap

NOTE: You must issue reset after swapoff for any ramzswap device. The reset causes all the (per-device) memory to be freed and performs lots of cleanups.

(ramzswap module unload calls reset for all initialized devices).

Following state diagram shows various ramzswap device states. The rzscontrol utility sends various ioctls to the ramzswap module to get/set information about individual devices. In the following figure, ioctl(--blah) means action taken when 'rzscontrol /dev/ramzswapX --blah' is done for /dev/ramzswapX device.

Figure 1: ramzswap device states.

* Changing memlimit for an active device is not yet implemented

저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

SmartAss Governor  (7) 2011.07.17
Dalvik-Cache  (1) 2011.04.05
RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
BFQ IO Scheduler  (9) 2011.03.24
Trackback 0 Comment 15
  1. 미친kamui 2011.04.01 01:17 신고 address edit & del reply

    ^^;; 쿨럭.. 램스왑까지.ㅠㅠ 이카루스님의 능력의 끝은 어디세요..

  2. 봉봉2 2011.04.01 10:46 신고 address edit & del reply

    매번감사합니다

  3. 김진원 2011.04.01 15:58 신고 address edit & del reply

    ㅜㅜ 전 암만봐도 어렵네요,, 고생 많으세요,,

  4. iCaRuS™ 2011.04.01 23:11 신고 address edit & del reply

    ㅎㅎ. 아~ramzswap.ko 모듈 빌드에, 커널패치및 컴파일까지 했는데,,,enable이 안되네요..
    휴..힘들다. 다시 해봐야겠어요~

  5. 소심아이 2011.04.01 23:22 신고 address edit & del reply

    이카루스님 정말 고생하십니다.. 펌업되고 최고의 커널로 나오길 기다립니다. ^^

  6. surellin 2011.04.02 09:03 신고 address edit & del reply

    안녕하세요. tc22펌용 스피드 커널을 절실히 기다리고 있습니다. ^^
    오랜만에 기다리면서 순정으로 사용중이군요. 미리 감사드립니다.

  7. 김종철 2011.04.02 10:16 신고 address edit & del reply

    저도 tc22 펌엄 안하고 이카루스님의 커널만 멀뚱멀뚱 기다리고 있습니다.
    감사합니다..

  8. skyjin0077 2011.04.02 12:55 신고 address edit & del reply

    오매불망, 이카루스님의 스피드커널만 기다리고 있습니다.
    외장 패치도 부두 7이 나와서 이카루스패치가 업글될걸로 믿는데 그게 오늘이면 얼마나 좋을까요? 일단 점심 먹고와서 또 들어와봐야죠...

  9. Jordan 1 KO 2012.05.29 15:51 신고 address edit & del reply

    덜컹 도로에서 시작된 브랜드 신발 산업에 가장 큰 영향 중 하나를 만드는 성장했으며이 날 때까지 계속 착용하고 자신의 외모를 칭찬했다.
    http://www.airjordan1ko.com/ Jordan 1 KO
    http://www.airjordan1ko.com/ Jordan Retro 1
    http://www.airjordan1ko.com/ Jordan 1

  10. Tom Brady Jersey 2012.07.07 11:11 신고 address edit & del reply

    5일(현지시간) 영국 텔레그래프에 따르면 나치 친위대장으로 강제수용소를 감독했던 하인리히 힘러는 1941년 8월27일 뒤셀도르프 게슈타포(나치 비밀경찰) 앞으로 한 통의 편지를 보냈다. 편지에는 '총통(히틀러)의 바람에 따라' 유대인 에른스트 헤스의 '구제와 보호'를 승인한다는 내용이 담겨 있었다. 앞서 히틀러는 헤스가 '박해 받거나 강제추방되지 않도록' 하라고 하달했고 힘러는 모든 관계 당국과 관리에게 헤스가 '어떤 식으로든 불편을 겪지 않도록 해라'고 지시를 내렸다. http://www.nikepatriotsjerseyonline.com/

  11. Jordan Retro 4 2012.07.09 10:21 신고 address edit & del reply

    그들이 게임에 참석하기 전에 히드로 공항은 런던과 영국의 첫 경험이 될 것입니다.공항은이 중대한 사건을 준비하기 위해 무엇입니까?
    http://www.jordan4firereds.com/ Jordan 4
    http://www.jordan4firereds.com/ Jordan Retro 4
    http://www.jordan4firereds.com/ Jordan 4 Fire Red
    http://www.jordan4firereds.com/ Jordan 4 Fire Red 2012
    http://www.jordan4firereds.com/ Jordan 4 Mars
    http://www.jordan4firereds.com/ Jordan 4 Mars 2012

  12. Jordan Retro 4 2012.07.23 15:35 신고 address edit & del reply

    지금까지 진정한 블루 왕족의 피가되고 꿈꿔왔다면 다음 법원, 당신에게 방법의 모든 단계를 지켜보고있는 공주로 통로를 따라 걷다. 아니면 스타에 빠진 사람이라면, 주위 유명 인사 impersonators와 결혼.
    http://www.fireredjordan4s.com/ Jordan Retro 4
    http://www.fireredjordan4s.com/ Jordan 4s
    http://www.fireredjordan4s.com/ Jordan 4 Fire Red
    http://www.fireredjordan4s.com/ Jordan 4 Fire Red 2012

  13. Lebron 9 For Cheap 2012.10.05 12:39 신고 address edit & del reply

    신발 주변의 고체 고무 outsole는 아름다운 꽃 생기고 이전의 어떤 르브론 신발 한 후 다른 서클, 사용하여 패턴을 가지고 있습니다. 이 모든 스타일과 디자인은 법원에 대한 더 나은 그립을 제공합니다. 그러나, 귀하의 패턴이 등장해야 블랙 잭 운동화가 제공하는 판매자의 그립이 크게 감소 될 동정 할 수 있습니다. http://www.lebronshoes2012.org

  14. Monster Beats Studio 2012.10.23 09:48 신고 address edit & del reply

    앱의 경로 확인engraving do the work is concluded be ghaarias, the enameling do the job is done be the enameler, the goldsmith looks following the gold or kundan get the function completed and eventually stone setters do operate of just surroundings the dear or semi-precious stone inside the holes inside the jewellery. hhjjkkllppuyiiuyasa http://greatmonsterbeats.com/categories/Monster-Beats-Studio/

  15. oakley sunglasses outlet 2013.04.15 03:59 신고 address edit & del reply

    쌀은 어떻게 구했지만,찬까지는 마련할 수 없었던 모양이다.

2011.03.28 21:34

BFQ-v2 IO Scheduler

오늘은, BFQ-v2에 대해 언급합니다.
BFQ-v2는 BFQ보다 fater~합니다.


BFQ-v2 provides the following four new features. According to my tests on 2.6.37 (extended and run with the valuable help of Mauro Andreolini), none of these features is paid with a loss of aggregate throughput with respect to BFQ-v1.
BFQ-v2 provides the same low-latency guarantees with and without NCQ. In other terms, differently from CFQ, latency guarantees are preserved also in presence of NCQ. For example: under a heavy workload and with BFQ-v2, it takes about two seconds to start konsole with and without NCQ on a medium-rate disk, whereas, under CFQ, it takes about 21 seconds without NCQ and about 2940 seconds (49 minutes) if NCQ is enabled.

The latency for interactive applications is about halved with respect to BFQ-v1.

When the low_latency tunable is set, also soft real-time applications now enjoy reduced latency (audio and video players/servers, music, ...). More in detail, when low-latency was enabled with BFQ-v1, only interactive applications were privileged, at the expense of non-interactive ones. This caused the latency experienced by soft real-time applications to grow, and become comparable to the one guaranteed by CFQ. Now, also soft real-time applications are properly privileged. For example, under heavy load and while other commands are repeatedly invoked, a video player enjoys about five-time-lower frame-drop rate than with CFQ.

A very little minimum bandwidth is now guaranteed to the Idle IO-scheduling class also when the other classes are backlogged, just to prevent the former from starving. In some situations, this starvation in turn happened to cause critical processes to block waiting for the disk indefinitely, which led to system livelock. For example, if konsole was repeatedly started and closed while two files were being read in parallel, then, after a few invocations, Xorg hung and login attempts from textual consoles blocked indefinitely (2.6.37, Ubuntu 10.10, files--the ones read in parallel--stored on a different partition w.r.t. to konsole and libraries). The actual bug is probably outside the block layer; however, differently from CFQ, with BFQ-v2 the system apparently does not hang anymore in this and other medium/heavy-load situations.
저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

Dalvik-Cache  (1) 2011.04.05
RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
BFQ IO Scheduler  (9) 2011.03.24
Loop Device  (1) 2011.03.21
Trackback 0 Comment 1
  1. burberry usa 2013.04.09 20:01 신고 address edit & del reply

    그들은 가난한 신혼부부였다.

2011.03.28 21:25

SIO I/O Scheduler ( Simple I/O Scheduler)

I/O Scheduler 중, BFQ이외에 SIO 란놈을 접하게 되었습니다.
SIO란 놈은 간단하게 말해서 아래와 같이 IO처리분배는 Deadline의 방식을 따르는 noop기반하에 만들어진 녀석입니다.
SIO 는 그 어떤것도 sort하지 않는 알골리즘으로 극소의 overhead를 발휘하며, 사전에 계획되지 않고 랜덤하게 엑세스되는 플래쉬 디바이스와 같은 장치를 위한 IO 스케쥴러의 알골리즘입니다.


          The Simple I/O scheduler is an extremely simple scheduler,
+          based on noop and deadline, that relies on deadlines to
+          ensure fairness. The algorithm does not do any sorting but
+          basic merging, trying to keep a minimum overhead. It is aimed
+          mainly for aleatory access devices (eg: flash devices).




저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

RAMZSWAP  (15) 2011.03.31
BFQ-v2 IO Scheduler  (1) 2011.03.28
SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
BFQ IO Scheduler  (9) 2011.03.24
Loop Device  (1) 2011.03.21
lowmemorykiller  (0) 2011.03.21
Trackback 0 Comment 2
  1. 안녕하세요 2011.05.04 19:52 신고 address edit & del reply

    그렇다면 sio가 효율성이 좋은건가요?

  2. Kobe 7 2012.08.16 11:42 신고 address edit & del reply

    이것은 사실 그것이 결정 실제로 쉽지 않네요 그리고 진짜인지 거짓이야, 확인을 위해 정말 항상 근본 아니다. 만약 어떤 미화 500 달러뿐만 아니라 미국 99달러 신발을 지니고있다면 함께 그들은 일반적으로 똑같 은데 그것은 아마도 가짜 아니면 그들이 어쩌면 가짜 모두이거나 그 또는 그녀가 모두 진짜 수도인가요? http://www.kobevii2012.com

2011.03.24 13:27

BFQ IO Scheduler


리눅스(안드로이드포함)의 디스크 IO는 스케쥴러라는 것을 통해 처리되며, 커널에서 옵션을 수정하여 변경이 가능합니다.


이카루스 SpeedMod Kernel에 사용한 IO Scheduler 는 BFQ, CFQ, Deadline 입니다.
삼성에서는 기본적으로 겔럭시 시리즈에 CFQ를 기본으로 적용시켜놓았습니다.

각 IO Scheduler는 각각 장점이 있으며, CFQ와 Deadline은 이카루스패치에도 잠깐 소개를 시켜드렸으므로, BFQ가 무엇인지 간략히 알아보겠습니다.

인터넷에서 검색을 해도, BFQ가 안드로이드에 더 좋고 성능도 CFQ보다 좋다는 말들이 많으며, XDA에서 개발되고 있는 프로젝트인 Cynoagen에서도 BFQ를 사용하고 있습니다.


-BFQ(Budget Fair Queueing): BFQ is a proportional share disk scheduling algorithm, based on CFQ
        예정된 스케쥴러를 순차적이고 효율적으로 공평하게 배분  디스크 사용을 관리해주는 역할을 한다.
        시스템 스케쥴러 우선순위에 따라 정직하고 공평하게 배분된 IO parameters를 스케쥴링한다


아래의 lwn.net의 자료를 보충으로 보기 바랍니다.
한마디로 CFQ의 향상된 버전이며, CFQ믄 시간개념으로 순차적인 스케쥴링정책을 라운드로빈(로드밸런싱)을 하지만,
BFQ는 시간이 아닌 sector의 수량으로 측정하여 스케쥴러를 정직하고 공평하게 배분한다는 개념이다.

아래 Lab Test에서도 보면 성능적으로 ( 특히 동영상 스트리밍) 에서 CFQ에 비해 보다 향상된 성능을 보여주고 있습니다.

lwn.net자료 아래의 Paolo 의 블로그 게제되어 있는 내용에서도, BFQ가 CFQ에 비해 모든 Workloads에서 최대30%의 throughput이 높다는 테스트자료도 있습니다.


<lwn.net자료>

   we are working to a new I/O scheduler based on CFQ, aiming at
improved predictability and fairness of the service, while maintaining
the high throughput it already provides.

The Budget Fair Queueing (BFQ) scheduler turns the CFQ Round-Robin
scheduling policy of time slices into a fair queueing scheduling
of sector budgets.  More precisely, each task is assigned a budget
measured in number of sectors instead of amount of time
, and budgets
are scheduled using a slightly modified version of WF2Q+.  The
budget assigned to each task varies over time as a function of its
behaviour.  However, one can set the maximum value of the budget
that BFQ can assign to any task.

The time-based allocation of the disk service in CFQ, while having
the desirable effect of implicitly charging each application for
the seek time it incurs, suffers from unfairness problems also
towards processes making the best possible use of the disk bandwidth.
In fact, even if the same time slice is assigned to two processes,
they may get a different throughput each, as a function of the
positions on the disk of their requests.  On the contrary, BFQ can
provide strong guarantees on bandwidth distribution because the
assigned budgets are measured in number of sectors.  Moreover, due
to its Round Robin policy, CFQ is characterized by an O(N) worst-case
delay (jitter) in request completion time, where N is the number
of tasks competing for the disk.  On the contrary, given the accurate
service distribution of the internal WF2Q+ scheduler, BFQ exhibits
O(1) delay.

We made several tests to measure the aggregate throughput, long-term
bandwidth distribution and single-request completion time guaranteed
by CFQ and BFQ; what we present here was obtained with an outdated
version of the code, we are in the process of collecting data for
the current one (see [1]).

In the first type of tests, to achieve a higher throughput than CFQ
(with the default 100 ms time slice), the maximum budget for BFQ
had to be set to at least 4k sectors.  Using the same value for the
maximum budget, in the second type of tests, BFQ guaranteed a maximum
deviation from the desired bandwidth distribution in the order of
3% over all the experiments.  On the contrary CFQ exhibited a maximum
deviation of 28% in consequence of the different positions of the
files on the disk.

Slowest task's bw (MB/s)  Fastest task's bw (MB/s)
-------------------------------------------------------------------
BFQ (2 files) 9.81 +/- 0.47 9.95 +/- 0.43
CFQ (2 files) 8.61 +/- 0.67 11.92 +/- 0.44
-------------------------------------------------------------------
BFQ (5 files) 4.29 +/- 0.10 4.31 +/- 0.09
CFQ (5 files) 4.01 +/- 0.17 5.24 +/- 0.14

Finally, we set up a VLC video streaming server to stream an
increasing number of movies in presence of disturbing ON/OFF random
file readers.  Each test ended when a 1% packet loss was reached
(a packet was deemed as lost if transmitted with a delayed of more
than 1 second).  With BFQ it was possible to transmit at most 24
movies in parallel (again with a 4k sectors maximum budget), against
15 movies with CFQ (with a time slice of 20 ms). 
This is likely
to be a consequence of the higher jitter of CFQ.

Nr. of movies Aggr. bw (MB/s)
---------------------------------------------------------------
BFQ (max_budget=4096) 24.00 +/- 0.00 7.56 +/- 0.87
BFQ (max_budget=16384) 18.70 +/- 9.45 12.78 +/- 5.64
CFQ (slice_sync=20)                 14.35 +/- 1.40 12.59 +/- 2.12

More stuff related to BFQ (extended results, the test programs used
and the setup for the tests, a document describing the algorithm in
detail and so on) can be found at:

[1] http://algo.ing.unimo.it/people/paolo/disk_sched/

We would greatly appreciate any sort of feedback from you, comments,
suggestions, corrections and so on.  Thank you for your attention.





<Paolo's Home>

BFQ is a proportional-share disk scheduling algorithm that also supports hierarchical scheduling with a cgroups interface. One of the nice features of BFQ is that, according to our results on rotational disks, it achieves six- to fourteen-time lower command startup times on a heavily loaded disk, with respect to CFQ, and at the same time up to 30% higher throughput with most workloads. In practice, whatever the disk load is, the system is virtually as responsive as if the disk was idle. BFQ also guarantees low latencies for soft real-time applications, as audio and video playing/streaming, music, and the like (about five times lower than CFQ). As for long-term guarantees, it distributes the disk throughput as desired to disk-bound applications, with any workload and independently of the disk parameters.

BFQ is currently used in the Zen Kernel as the default disk scheduler. As such, it can be found also in distributions as Gentoo Linux. I also recorded downloads from people using other distributions as, e.g., Ubuntu, Mandriva and ArchLinux. Finally, the CyanogenMod distribution of Android switched to BFQ too. In the end, BFQ should be exposed to a userbase in the order of 200K users. So far, the users that gave us feedback confirmed the expected latency drop and throughput boost in daily usage.

In these pages you can find a brief description of the properties of BFQ and of how it works, together with the scheduler interface, the available tunables and the TODO list. You can download the sources, and see some benchmark results. Finally, there is a comparison with other production and research schedulers, including a thorough performance evaluation, carried out using an older implementation of BFQ.



< Test Results>



Here you can find an annotated summary of the results for bfq-v1 under 2.6.32/33/34/35/36 for several benchmarks (all the tests I have not yet run are pointed out too). As for bfq-v2, its improvements over v1 are described here.

The relative performance between bfq and cfq is quite similar under any of these kernels. Hence, for brevity, only the results with 2.6.34 are described at length. For 2.6.33 I point out only the cases where the results differ significantly from the ones with 2.6.34. In a similar vein, what happens with 2.6.32 and 2.6.35 is only shortly summarized at the end of each section. Finally, under 2.6.36 the relative performance of bfq with respect to cfq for any of the tests is better than under the other schedulers. So the results for 2.6.36 are not reported at all.

To get these results I implemented this benchmark suite, have a look at the README and the programs therein.

The tests have been run on the following three systems with 2.6.32/33/34/35/36 (the reported peak rates have been measured with hdparm):

DISK					CPU			DISTRIBUTION	FS
ATA MAXTOR 6L080L0 (82 GB, 55 MB/s)	Athlon 64 3200+		Slackware 13.0	ext3
ATA MAXTOR 7L250S0 (250 GB, 61 MB/s)	Pentium 4 3.2GHz	Ubuntu 8.04	ext3
ATA MAXTOR STM332061 (320 GB, 89 MB/s)	Athlon 64 3200+		Ubuntu 10.04	ext4

For short, I will call each of these systems just the slow, medium or fast disk. Still to do: I did not yet run tests on RAIDs.

In all the tests the low_latency tunable of cfq was on. Each test was repeated ten times, and the values shown in the sections below are averages computed over these repetitions. The statistics I collected are however much more detailed: min/max/avg/standard deviation/confidence interval for several quantities (latency, read/write/ total aggregated throughput, ...) have been computed within each test and across multiple repetitions of each test. All these numbers, for the fast disk, can be found in this archive.

The results with 2.6.33 and 2.6.34 are essentially similar. However, whereas bfq was quite stable, cfq got slightly better results with 2.6.34. In contrast, with 2.6.35 the latencies achieved by bfq are definitely lower than with all the other kernels. So, for brevity I report here only the results with 2.6.34, apart from where they differ significantly wioth respect to 2.6.33. In that case also the results with 2.6.33 are reported. As previously said, the results with 2.6.32 and 2.6.35 are only shortly summarized at the end of each section.

COLD-CACHE STARTUP LATENCY OF SHORT COMMANDS

Executing short commands from a shell should be a common task for
which one may desire low latency on a desktop or server. To get an
idea of the latency guaranteed by bfq to these commands in presence of
peak disk workloads, I measured the time to launch some of them with
cold caches and while one of the following sets of readers/writers
were being executed in parallel: ten sequential readers (hereafter
called 10r-seq for short), ten random readers (10r-rand), five
sequential readers plus five sequential writers (5r5w-seq), five
random readers plus five random writers (5r5w-rand).

One of the commands tested was "bash -c exit". On the fast disk it was
executed in 0.32 seconds with 10r-seq or 0.41 secs with 10r-rand,
against 0.55 or 0.33 secs under cfq. This time boiled down to 0.20
secs with 5r5w-seq or 0.26 secs with 5r5w-rand, against 0.57 or 0.66
under cfq. Hence, apart from the 10r-rand case, where cfq provides a
0.08 secs lower latency, the latency with bfq is from almost 2 to
almost 3 times lower than with cfq. Consider that bfq achieves these
results without using any additional mechanism/policy to favour
latency-sensitive applications, as cfq instead does.

In each of the ten repetitions of the test, "bash -c exit" was
executed ten times, spaced by 1 second from each other. Under these
conditions, the disk aggregated throughput with bfq was 72.2 MB/s with
10r-seq and 73.2 MB/s with 5r5w-seq, against 59.9 MB/s and 56.6 with
cfq. With regard to random workloads, with bfq I got 0.74 MB/s with
10r-rand and 1.04 MB/s with 5r5w-rand, against 0.64 MB/s and 0.85 with
cfq. In the end with bfq the throughput was from about 15% to about
30% higher.

This lower latency/higher throughput result is probably due to the
more accurate scheduling policy of bfq, which allows it get a low
latency even if assigning high budgets to the readers. More in detail,
the maximum possible budget that could be assigned was equal to the
estimated maximum amount of sectors that could be transferred in 125 ms
(the default budget timeout) on the target disk. And we verified that
bfq did assign such high budgets.

On each of the other two disks bfq got similar relative performance
against cfq as on the fast disk.  These latency results with short
commands should also confirm that bfq guarantees low latency to
periodic soft real-time applications, as we showed a while ago with
our experiments on video streaming.
See the performance comparison for those results on video streaming.
As for 2.6.32, bfq got similar results as with 2.6.33/34 kernels, whereas
cfq latencies grew by 3-4 times with 10r-seq and 5r5w-seq (with respect
to the latencies it achieved with the other kernels). In contrast, cfq
achieved approximately the same latencies as with the other kernels in case
of 10r-rand and 5r5w-rand. About the throughput, cfq provided a 14% higher
aggregated throughput than bfq with 10r-seq, but it lost the same percentage of
throughput with respect to bfq with 5r5w-seq. With 10r-rand and 5r5w-rand
cfq achieved approximately the same throughput as under the other kernels.

Also with 2.6.35 bfq achieved similar results as with the other
kernels.  cfq got similar results too in terms of aggregated
throughput. In contrast latencies were higher with most workloads,
especially 4.7 times higher with 5r5w-rand.


STARTUP LATENCY OF LONGER COMMANDS

What happens with longer commands? The main purpose of the scheduling
policy of bfq is fairness. As the size of the stuff that has to be
read to execute a command grows, fairness constraints become dominant
in determining how long it will take to complete the command on a
loaded disk. For example, if the disk is idle, it takes about 2
seconds to execute "konsole -e /bin/true" on the fast disk with cold
caches. And it takes around 19.9 secs with bfq if ten files are being
read at the same time, as fairness demands. This is still less than
the 26 secs measured with cfq, but it is definitely a long wait for a
user.

The appropriate, general solution would be at least assigning the
right weight to each application according to its requirements
(probably something more sophisticated is needed). Of course this
should be done somewhere above the block layer, which is definitely
out of the business of bfq :)
However, I tried to give the following low_latency tunable a try ...


EXPERIMENTAL LOW_LATENCY TUNABLE FOR BFQ, AND CAVEATS

When this tunable is on, the original weight of a just born queue is
multiplied by ten, then it is linearly decreased as the queue gets
service, until it becomes equal to the original weight. Especially,
with the current values of the parameters, the boosting is over, i.e.,
the original weight is reached, when the queue has got about 24MB
served. To prevent seeky processes from keeping a high weight for too
long, a queue has 6 seconds (real time) to consume these 24MB, after
which the boosting is unconditionally suspended. If an existing queue
becomes backlogged after being idle for 20 seconds or more, then it
enjoys this weight boosting again. Of course I got to these numbers
after some tuning or common sense (I hope :) ).

This mechanism is a source of unfairness against disk-bound long-lived
processes, which do not benefit from any weight boosting. Probably low
latency is almost always not worth this loss of fairness on a
server. In contrast, the user of a desktop may be willing to tolerate
a temporary drop of throughput of long-lived best-effort applications
(download, peer-to-peer exchange, ..) in return of a lower latency of
the task being started.

On the contrary, few users would be happy if their long-lived soft
real-time applications, as e.g. video or audio players, suffered from
increased latencies. To check this, I repeated several times the
following experiment with both bfq and cfq: 1) flushed caches, 2)
started playing a high-resolution film with mplayer, 3) started ten
sequential or random readers when the film reached a given point, 4)
measured the number of dropped frames after 10 seconds (shown on the
status line of the player). These are the results on the slow disk
(the one on which frame drops were of course higher). Apart from a few
unlucky runs for both schedulers, the results were more or less stable
around the following averages:

 Number of dropped frames - slow disk - BFQ vs CFQ
Avg with 10 seq readers | Avg with 10 rand readers |
    6 vs 10             |           5 vs 5         |

According to this test the boosting mechanism apparently causes no
harm with respect to what is guaranteed by cfq. This parity seems also
to suggest some caution in adding a similar mechanism to cfq.

One of the shortcomings of this test is the following. Since it was
better to give you numbers and not my impressions of how smoother the
video was played with bfq, I run this mplayer test on the three
systems remotely for practicality, with -ao null and -vo null. So, to
release bfq in this millennium, I did not yet perform also systematic
tests of loss of video/audio quality on real use cases (listening to
music, watching a movie, maybe an HD one). Iteratively launching
batches of file reads while playing back music is not my typical daily
activity :)

Now I can show you what happens after turning low_latency on in bfq.


COMMAND STARTUP LATENCY WITH LOW_LATENCY ON

Repeating the same test for "bash -c exit", the startup time falls to
at most 0.20 secs with any of the sequential workloads and at most
0.23 secs with any of the rand workloads. Hence it is always from
about 1.5 to about 3 times lower than cfq. Aggregated throughput
performance are substantially the same as with low_latency off.

Now the actual litmus test: "konsole -e /bin/true" :)
The results are summarized in the following table (it reports
latency/agg. throughput with bfq vs latency/agg. throughput with cfq):

	konsole startup - fast disk - BFQ vs CFQ
 Background workload |  Latency [sec]   | Agg. thr [MB/s]
---------------------------------------------------------
	10r-seq      |   2.88 vs 26.03  | 48 vs 58
	5r5w-seq     |   2.59 vs 14.18  | 71 vs 57
	10r-rand     |   2.87 vs 22.36  | 5.5 vs 1.5
	5r5w-rand    |   2.82 vs 13.03  | 5.8 vs 2.0

The latency drop is evident. The 9-times lower latency with 10r-seq is
however paid with a 20% loss of aggregated throughput, because with
this highly sequential workload the throughput fall is more pronounced
as the seeky pattern of konsole is favoured. In the other three cases
the aggregated throughput is always higher even if the latency is at
least 4.6 times lower.

I tested also "xterm /bin/true" and found that under bfq it is
executed in no more than 0.4 secs with any of the workloads, against
around 2.4 to 4.6 secs under cfq (depending on the
workload). Aggregated throughput performance is in the middle between
the results with konsole and with bash. On each of the other two disks
the relative performance of bfq against cfq was more or less the same
as on the fast disk, for any of the three commands.

As for 2.6.32, bfq got again approximately the same results as wih the
2.6.33/34 kernels. On the contrary, the latencies with cfq grew up to
46 seconds for konsole, and 5.4 seconds for xterm, with 10r-seq. The
relative performance with respect to bfq in terms of aggregated
throughput was similar to the one with the bash tests under 2.6.32.

Also with 2.6.35 bfq exhibited about the same performance as with the
other kernels. The same happened to cfq in terms of aggregated
throughput. The latencies of cfq were instead quite worse: up to 34.5
secs for konsole and 5.3 secs for xterm. In the end the konsole and
xterm execution times with bfq were from about 6 to about 14 times
lower than with cfq.


KERNEL DEVELOPMENT TASKS (MAKE, CHECKOUT, MERGE)

I measured how much a kernel make, git checkout or git merge
progresses while one of the usual four workloads considered so far is
being served. About the 5r5w-seq and 5r5w-rand workloads, I verified
that they let these tasks almost starve with both schedulers. In fact,
a significant part of the work done by these tasks is writing files,
but writes are system-wide and end up in common flush queues. So a
per-queue disk scheduler has apparently no opportunity to save the
writes generated by these tasks from being overwhelmed by the ones of
relentless greedy writers. Thus I report here only the results with
the two workloads comprised of only readers.

Let us start with make. As I verified through tracing, each cc1
invoked by make generates really few read requests, usually served in
about 100 ms under bfq. Then it spends the (definitely longer) rest of
its life either using the CPU or waiting for its writes to be handed
over to the vm subsystem. In the end, most of the (little) control of
a disk scheduler over the progress of a task like this is related to
how the scheduler proportions writes with respect to reads. And bfq
does it more or less as cfq does on both the slow and the fast
disks. On the contrary, under 2.6.33 bfq throttles writes more than
cfq on the medium disk, and this has negative consequences, as shown
last. First, here are the results for make on the fast disk:

	         make - fast disk - BFQ vs CFQ
 Background workload | Number of source files   | Agg. thr [MB/s]
	   	     | compiled during the test |
------------------------------------------------------------------
	10r-seq      |  219 vs 197              | 74 vs 57
	10r-rand     |  261 vs 270              | 0.7 vs 0.7

As can be seen, whereas the number of files compiled is about the same
with any of the two schedulers, the aggregated throughput with bfq is
higher with 10r-seq.

Things differ in case of git merge and git checkout. 

         git merge / git checkout - fast disk - BFQ vs CFQ
Background workload  | Progress of merge | Progress of checkout
	   	     | during the test   | during the test
------------------------------------------------------------------
	10r-seq      |  19% vs 1.3%      | 15.5% vs 2.5%
	10r-rand     |  25% vs 2.6%      | 40.7% vs 16.1%

The reason for these better results may be that the two tasks are more
read-intensive than a make; but we did not investigate this issue
further. With both tasks the relative performance of the schedulers in
terms of aggregated throughput is close to the one with make.

The relative performance of bfq with respect to cfq on the other two
disks are similar to the one on the fast disk. As anticipated, the
performance is instead worse on the medium disk with 2.6.33. On this
system bfq reduces the write throughput by 26% to 50% with respect to
cfq in presence of sequential readers. Here are the consequences:

   make / git merge / git checkout - medium disk 2.6.33 - BFQ vs CFQ
Backgr. workload  | Num. files compiled | Progr. of merge | Progr. of checkout
	   	  | during make test    | during the test | during the test
-----------------------------------------------------------------------------
	10r-seq   |       55 vs 134     |   5% vs 4.9%    | 3.2% vs 3%
	10r-rand  |      286 vs 131     |  13.9% vs 5.8%  | 17.2% vs 12.41%

The improvement of bfq drops with merge and checkout, and the
performance is even worse than cfq for make with sequential readers.
Yet bfq is definitely better than cfq for make with random
readers. These results with 2.6.33 should be further investigated.

As for 2.6.32, bfq achieved about the same results, whereas cfq got
quite poor results in terms of progress of each of the tasks. For
example, merge with 10r-seq progressed, under cfq, 77 times less than
under bfq. About the throughput, cfq got up to 40% higher aggregated
throughput with respect to bfq with 10r-seq, but lost up to 200% of
the throughput with 10r-rand.

Under 2.6.35 the relative performance of bfq with respect to cfq was quite
better than under 2.6.34.


AGGREGATED THROUGHPUT

As said several thousands lines ago, on one hand bfq quickly assigns
high budgets to non-seeky queues. On the other hand, the budget
timeout mechanism lets it naturally switch to a safe time slice scheme
for seeky queues, essentially the same as cfq. Here are the results of
these facts:

aggregated throughput - fast disk - BFQ vs CFQ
 Workload  | Agg. thr [MB/s]
---------------------------------------
10r-seq    |   82.4 vs 66.1
5r5w-seq   |   77.2 vs 62.4
10r-rand   |   0.60 vs 0.60
5r5w-rand  |   0.71  vs 0.83

Similar relative performance on the other two disks. I also
investigated a middle-ground scenario where two out of three
sequentially read files were interleaved on the disk surface (written
by running two dd in parallel). bfq achieved a higher throughput than
cfq also in this case. The analysis of these type of workloads has not
yet been deepened.

As for 2.6.32, the relative performance between bfq and cfq was essentially
the same as in the bash tests under 2.6.32.

Finally, these were the results under 2.6.35 with the fast disk:

aggregated throughput - fast disk - 2.6.35 - BFQ vs CFQ
 Workload  | Agg. thr [MB/s]
---------------------------------------
10r-seq    |   81.0 vs 63.6
5r5w-seq   |   74.8 vs 62.0
10r-rand   |   0.70 vs 1.1
5r5w-rand  |   1.0  vs 0.64


FAIRNESS

As you most certainly know, bfq works in the service, and not in the
time domain. This peculiar feature allows it to distribute the disk
throughput to non-seeky processes as desired (i.e., according to the
assigned weights). In particular, the desired throughput distribution
is guaranteed under any workload and independently of the disk
physical characteristics.

On the contrary, it is the disk time to be fairly distributed with
cfq. Due to ZBR, this results in unfairness in distributing the disk
throughput, in proportion to the distance between the files being
read/written.
We already showed this fact with a varying number of parallel reads,
see our old comparative tests.
Repeating some of those tests on the fast disk, I saw, for example,
that two parallel readers of two 500MB distant files run at 32.1 and
32.2 MB/s with bfq, against 34.1 and 30.7 MB/s with cfq. In practice
bfq equally redistributes the excess throughput given by cfq to the
process that reads the file in the faster zone of the disk. In
addition, under cfq the unlucky reader finishes later than any of the
two readers under bfq. Hence bfq also in this case enjoys a higher
average aggregated throughput.

As I saw from the traces, fairness and throughput are unsurprisingly
also related to when bfq treats a queue as seeky and when it does not.
And even sequential readers generate a seeky workload during part of
their life. Hence there may still be room for improvement, to increase
the throughput of each reader. In addition, further tuning might be
needed to get high throughput and/or fairness with workloads that I
did not yet consider. I did not yet look into these issues
further. Finally, thorough testing with differentiated weights is
still missing too.
 
 
 
<Comparision>

In this long page you can find a comparison among BFQ, SCAN-EDF, YFQ, CFQ, C-LOOK and Anticipatory. You can also find all the stuff related to the first implementations of BFQ, YFQ and SCAN-EDF made by Fabio Checconi and me, and to the performance tests we ran with each of these six schedulers.

  • Budget Fair Queueing (BFQ) is a Proportional Share, or equivalently Fair Queueing, disk scheduler that allows each process/thread to be assigned a fraction of the disk bandwidth. BFQ assigns a budget, measured in number of sectors, to each process and serves budgets according to B-WF2Q+, a modified version of WF2Q+.
  • Yet another Fair Queueing (YFQ) is a research scheduler based on the same bandwidth allocation scheme as BFQ, but it serves requests, possibly of different processes, in batches.
  • SCAN Earliest Deadline First (SCAN-EDF) is a research real-time disk scheduler in which each request is associated with a completion deadline, and the requests with the earliest deadline have the highest priority.
  • CFQ and Anticiptory (AS) are two Linux schedulers: the first serves each process for a given time slice in a Round-Robin fashion, whereas, as C-LOOK, the second serves requests in ascending position order.

BFQ, CFQ and AS (may) adopt disk idling to handle deceptive idleness. In addition to the top-level description of how BFQ works, you can find all the details about the algorithm, deceptive idleness and other issues in this technical report (to appear on Transactions on Computers). We could not find any Linux implementation of either YFQ or SCAN-EDF. So, to compare both schedulers against BFQ, we implemented them for 2.6.21. Especially, this is the patch that adds BFQ, SCAN-EDF and YFQ to 2.6.21.

The first BFQ proposal (for 2.6.25) was recorded on kerneltrap.org by Jeremy Andrews, whereas the second one (extended version for 2.6.28-rc4) was reviewed on lwn.net by Goldwyn Rodrigues. See the home of this mini-site for the latest available BFQ patches.

In the rest of this page we report a comparison among BFQ, YFQ, SCAN-EDF, CFQ, AS and C-LOOK. Then a summary of the results of our experiments.
A longer description and comparison of the schedulers, together with a more detailed description of the experiments and of the results can be found in the above mentioned technical report. Finally, all the results and the programs used to generate them can be found in this compressed file.

Comparison among the six schedulers

BFQ has been designed to achieve high throughput and tight guarantees, in terms of both bandwidth distribution and request completion time.

Especially, defined the reserved service of a process over a time interval as the minimum amount of service that, according to its reserved fraction of the disk bandwidth, the process should receive during the time interval, BFQ guarantees to each process an O(1) deviation, over any time interval, with respect to its reserved service. BFQ owes to CFQ the idea of exclusively serving each application for a while.

The time-based allocation of the disk service in CFQ has the advantage of implicitly charging each application for the seek time it incurs. Unfortunately this scheme may suffer from unfairness problems also towards processes making the best possible use of the disk bandwidth. In fact, even if the same time slice is assigned to two processes, they may get a different throughput each, as a function of the positions on the disk of their requests. On the contrary, BFQ provides strong guarantees on bandwidth distribution because the assigned budgets are measured in number of sectors. Moreover, due to its Round Robin policy, CFQ is characterized by an O(N) worst-case jitter in request completion time, where N is the number of processes competing for the disk. On the contrary, thanks to the accurate service distribution of the internal B-WF2Q+ scheduler, BFQ exhibits O(1) delay.

To prevent seeky processes from (over)lowering the throughput, if a process is consuming its budget too slowly, it is deactivated and unconditionally (over)charged with a maximum budget. See the code for details.

Differently from BFQ and CFQ the original SCAN-EDF and YFQ algorithms do not take the deceptive idleness problem into account. However, in our implementations, we added the waiting for the arrival of the next requests for at most Tw seconds before serving the next request or batch of requests.

Despite this extension, YFQ still achieves a low throughput and fails to guarantee the desired bandwidth distribution in presence of synchronous requests (see the section on the experimental results). When asked for the next requests to serve, YFQ dispatches an entire batch, which in general contains requests issued by different processes. First, this reduces the possibility of near or sequential accesses of the same processes. Second, if an application has a (much) higher weight than the others but it issues synchronous requests, then no more than one request of the application will be however served for each batch.

Another problem shared by YFQ, SCAN-EDF and all the timestamp-based scheduler we are aware of, and dealt with in BFQ through some special timestamping rules, is that if a scheduler delays the completion of a request, it actually delays the arrival of the next synchronous request of the same process. If these delayed requests are not treated in some special way, the process looks like asking for less bandwidth than expected.

Actually, in a pure real-time environment, arrivals are known beforehand and are independent of completion times. However, real-time schedulers may be used to define bandwidth servers that insulate processes issuing requests with unknown arrival times. In this respect, in our implementation of SCAN-EDF, each process is associated with a relative deadline -- equal e.g., to the process' period -- which is is assigned to each request issued by the process. The (absolute) deadline of each request is then computed as the sum of the relative deadline and the maximum between the request arrival time and the deadline of the previous request of the same application. The resulting algorithm can be seen as a simple EDF-based bandwidth server: in a full-loaded system, each process should be guaranteed a bandwidth equal to the size of its requests divided by their relative deadline.

Unfortunately, this guarantee is violated for processes issuing synchronous requests. Deadlines may be missed, mainly because of the non-preemptability of request service, hence the arrival of synchronous requests may be delayed. As confirmed by the experimental results, the expected guarantees are violated because the absolute deadlines of the delayed requests are computed as a function of these deceptively delayed arrival times.

Summary of the results

In this section we report the results of our experiments with BFQ, SCAN-EDF, YFQ, CFQ, C-LOOK and AS in the Linux 2.6.21 kernel.

We used a PC equipped with a 1 GHz AMD Athlon processor, 768 MB RAM, and a (old) 30 GB IBM-DTLA-307030 ATA IDE hard drive (roughly 36 MB/sec peak bandwidth in the outer zones, ~35% lower throughput in the inner zones), accessed in UDMA mode, NCQ not available (see the draft for a discussion about the loss of guarantees caused by NCQ/TCQ). This low performance disk device helped us guarantee that it was the only bottleneck.

Then we ran several experiments aimed at measuring the aggregate throughput and long-term bandwidth distribution with parallel sequential reads, (small) file completion time/(large file) bandwidth distribution/aggregate throughput for a (seeky) Web server-like workload, request completion time and aggregate throughput for a DBMS-like random workload, and single-request completion time for a video streaming application guaranteed by the 6 schedulers. Each experiment was repeated 20 times. In what follows any mean value v is reported in the form v +/- s, where s is the semi-width of the 95% confidence interval for v.

Our implementation of SCAN-EDF exports a system-wide deadline granularity parameter. By increasing/decreasing the value of this parameter one can increase/decrease the likelihood that more requests with close deadlines are served in SCAN order.

We do not report here the detailed description of the experiments (see the draft), but only the main results.

Aggregate throughput

For any scheduler, the lowest aggregate throughputs were achieved in case of 2, 128 MB long, files, lying on two slices at the maximum distance from each other on the disk. For this scenario, the following table reports both the maximum value of the mean aggregate throughput achieved by the six schedulers and the value of the configuration parameter for which this maximum was achieved:

Scheduler
Parameter
Mean Agg. Thr. [MB/s]
Parameter Value
BFQ
22.46 +/- 0.81
Max budget = 16384 sects
CFQ
16.91 +/- 1.30
Time slice = 100 ms
SCAN-EDF
Tw=0ms
21.18 +/- 0.47
Deadline gran. = 640 ms
Tw=4ms
23.39 +/- 0.51
YFQ
Tw=0ms
10.64 +/- 0.25
Batch size = 16 reqs
Tw=4ms
10.80 +/- 0.20
C-LOOK
20.59 +/- 0.76
AS
32.97 +/- 1.89

Whereas the highest throughput is achieved by AS, the bad performance of C-LOOK is due to the fact that it frequently switches from one file to the other, for it does not wait for the arrival of the next synchronous request of the just served application.

The high throughput achieved by BFQ results from the high number of (sequential) sectors of a file that can be read before switching to the other file. Considering the disk peak transfer rate, it is easy to see that a lower and a higher number of sequential reads are allowed, respectively, by CFQ in a 100 ms slice, and by SCAN-EDF with a granularity of 640 ms. Notably, Tw does not influence much the aggregate throughput with SCAN-EDF. In fact, the system performs read-ahead, hence it tends to asynchronously issue the next request before the completion of the current one.

To evaluate the possible trade offs between guarantee granularity and aggregate throughput with BFQ, it is necessary to know how the throughput varies as a function of the maximum budget in the worst-case scenario. This piece of information is shown in the following figure in case of simultaneous sequential read of 2, 128 MB long, files. The aggregate throughput of CFQ, AS and C-LOOK are reported as a reference too. As can be seen, for a maximum budget equal to 4096 sectors BFQ guarantees a higher throughput than CFQ

 

 
 

Bandwidth distribution

We first considered the case where all the processes are allocated the same fraction of the disk bandwidth. For each scheduler, the highest deviation from the ideal distribution occurred for 128 MB long files. Moreover, the results for 3 and 4 files "stay between" the ones achieved for 2 and 5 files. Hence, for brevity, we report here only the results for 2 and 5, 128 MB long, files.

For BFQ we only report the results for a maximum budget equal to 4096 sectors. Similarly, for SCAN-EDF, we consider only a deadline granularity of 80 ms because for this value SCAN-EDF achieves an aggregate throughput close to BFQ. In our experiments the batch size had no influence on the guarantees provided by YFQ. We report the results for a batch size of 4 requests. Finally, we consider only Tw=4 ms for SCAN-EDF and YFQ.

Throughput [MB/s] (2 files)
9.95 +/- 0.43
9.81 +/- 0.47
Throughput [MB/s] (5 files)
4.29 +/- 0.10
4.30 +/- 0.09
4.30 +/- 0.07
4.29 +/- 0.10
4.31 +/- 0.09
BFQ (Maximum budget = 4096 sectors)

Throughput [MB/s] (2 files)
11.92 +/- 0.44
8.61 +/- 0.67
Throughput [MB/s] (5 files)
5.24 +/- 0.14
4.91 +/- 0.15
4.66 +/- 0.11
4.37 +/- 0.10
4.01 +/- 0.17
CFQ (Time slice = 100 ms)

Throughput [MB/s] (2 files)
11.52 +/- 1.78
10.57 +/- 0.55
Throughput [MB/s] (5 files)
5.56 +/- 0.67
5.14 +/- 0.41
5.05 +/- 0.50
4.95 +/- 0.35
4.83 +/- 0.09
C-LOOK

Throughput [MB/s] (2 files)
10.72 +/- 0.22
9.62 +/- 0.19
Throughput [MB/s] (5 files)
2.17 +/- 0.02
2.17 +/- 0.02
2.17 +/- 0.02
2.17 +/- 0.02
2.19 +/- 0.03
SCAN-EDF (Deadline gran. = 80 ms, Tw=4 ms)

Throughput [MB/s] (2 files)
5.44 +/- 0.10
5.44 +/- 0.10
Throughput [MB/s] (5 files)
1.39 +/- 0.02
1.39 +/- 0.02
1.39 +/- 0.02
1.39 +/- 0.02
1.39 +/- 0.03
YFQ (Batch size = 4 requests, Tw=4 ms)

Throughput [MB/s] (2 files)
32.41 +/- 13.39
17.78 +/- 1.10
Throughput [MB/s] (5 files)
32.83 +/- 11.95
31.72 +/- 1.37
29.80 +/- 0.50
12.56 +/- 10.46
18.29 +/- 0.43
AS

BFQ and YFQ exhibit the most accurate bandwidth distribution. Unfortunately, as previously seen, YFQ has a low throughput. SCAN-EDF is less accurate for 2 files, but it provides a higher throughput than YFQ. Finally, consistently with the previous arguments, CFQ fails to fairly distribute the throughput because of the varying sector transfer speed.

Moreover the high width of the confidence interval for AS is a consequence of the fact that sometimes the waiting timer may expire before the next synchronous request arrives. In that case also AS switches to the service of another application.

However, the accurate throughput distribution of YFQ and SCAN-EDF is mostly related to the symmetry of the bandwidth allocation. To measure the accuracy of the schedulers in distributing the disk bandwidth in case of asymmetric allocations, under BFQ and YFQ we assigned different weights to the (file read) processes. Of course, the length of each file was proportional to the weight of the application that had to read it. We ran two sets of experiments, using, respectively, the weights 1 and 2, and the weights 1, 2 and 10.

To try to allocate the same bandwidth as with BFQ and YFQ, under SCAN-EDF we assigned to each request of a process a relative deadline inversely proportional to the weight assigned to the process under the other two schedulers. Finally, this type of experiments was not run for CFQ, C-LOOK and AS because of the incompatibility between the concepts of weight and priority (CFQ, although, in the code of the current version it is possible to see the correspondence between priority and slice duration), or the lack of any per-application differentiated policy (C-LOOK and AS).

Finally, since, as in the previous experiments, the results for 3 and 4 files "stay between" the ones achieved for 2 and 5 files, for brevity in the following tables we report the results with BFQ only for the 2 and 5 files scenarios.

Weight
2
2
2
1
1
Throughput [MB/s] (2 files)
14.62 +/- 0.60
7.31 +/- 0.32
Throughput [MB/s] (5 files)
5.60 +/- 0.08
5.60 +/- 0.08
5.60 +/- 0.08
2.81 +/- 0.04
2.81 +/- 0.04

Weight
10
2
2
1
1
Throughput [MB/s] (2 files)
26.81 +/- 0.60
2.77 +/- 0.16
Throughput [MB/s] (5 files)
16.06 +/- 0.28
3.25 +/- 0.07
3.25 +/- 0.07
1.64 +/- 0.04
1.65 +/- 0.04

BFQ (Maximum budget = 4096 sectors)

With regards to SCAN-EDF and YFQ, both failed to guarantee the desired bandwidth distribution in all the experiments. For example, in case of 2 applications with weights 10 and 1, the throughputs were {26.58 +/- 0.50, 6.92 +/- 0.20} MB/s for SCAN-EDF, and {22.70 +/- 0.12, 5.41 +/- 0.12} MB/s for YFQ (the deviation from the expected throughputs is even attenuated by the fact that the process with a higher weight has to read a longer file, and hence it gets exclusive access to the disk after the other one finished).

Latency/Bandwidth/Aggregate throughput (Web server)

We generated the following Web server-like traffic: 100 processes (all with the same weight/priority) continuously read files one after the other. Every 10 files, each process appended a random amount of bytes, from 1 to 16 kB, to a common log file. Each of the files to read might have been, with probability 0.9, a small 16kB (html) file at a random position in the first half of the disk, or, with probability 0.1, a large file with random size in [1, 30] MB at a random position in the second half of the disk. Such a scenario allows the performance of the schedulers to be measured in presence of a mix of both sequential (large files) and a seeky traffic (small files). Especially, for each run, lasting for about one hour, we measured the completion time of each small file (latency), the (average) bandwidth at which large files were read and the average aggregate throughput (measured every second). In this respect, small and large file reads were performed in separated parts of the disk to generate an asymmetric workload, which is more prone to higher latencies and/or lower bandwidths. The table below shows the results obtained with all the disk slices mounted with NOATIME (see the compressed file for the results with ATIME).

Scheduler
Completion time
small files [sec]
Bandwidth
large files [MB/s]
Mean Aggr. Thr. [MB/s]
BFQ
1.74 +/- 0.11
2.26 +/- 2.34
17.13 +/- 0.65
CFQ
3.86 +/- 0.17
2.97 +/- 2.47
18.20 +/- 0.79
SCAN-EDF
7.68 +/- 0.20
3.29 +/- 3.10
8.71 +/- 0.09
YFQ
0.40 +/- 0.01
1.36 +/- 1.71
6.87 +/- 0.09
C-LOOK
7.78 +/- 0.27
9.65 +/- 3.93
19.47 +/- 0.66
AS
7.69 +/- 0.27
16.61 +/- 4.00
20.60 +/- 1.22

As can be seen -- excluding for a moment SCAN-EDF and YFQ -- BFQ, CFQ and AS stand, respectively at the beginning, (about) the middle and the end of the low latency versus high aggregate throughput scale. In contrast YFQ has very low latencies and throughput because, as the probability of a small file read is 9 times higher than the one of a large file read, each batch is likely to contain a high percentage of requests pertaining to small files. In general, the low aggregate throughput achieved by SCAN-EDF and YFQ may be imputed to the fact that, differently from all the other schedulers, they do not take any special countermeasure to keep the throughput high against seeky workloads. With any scheduler, the high width of the confidence interval for the mean bandwidth of the large files is a consequence of the almost completely random nature of the workload.

DBMS

This set of experiments was aimed at estimating the request completion time and the aggregate throughput achieved by the schedulers against a DBMS-like workload: 100 processes (all with the same weight/priority) concurrently issue direct (non cacheable) 4KB read requests at random positions in a common 5GB file. We have used this setup to evaluate also the performance of the schedulers with asynchronous requests, and, to this purposes, we have run 10 variants of the experiment, with each variant characterized by a different number of per-process outstanding requests, ranging from 1 (synchronous requests) to 10. According to our results, for each scheduler both the request completion time and the aggregate throughput monotonically grew with the number of outstanding requests. Hence, for brevity we report in the following table the mean request completion time and aggregate throughput only for 1 and 10 outstanding requests.

center>
Scheduler
Number of
outstanding
requests
Completion
time [sec]
Mean aggr.
throughput [MB/s]
BFQ
1
0.92 +/- 0.12
0.44 +/- 0.00
10
7.93 +/- 0.29
0.49 +/- 0.00
CFQ
1
0.91 +/- 0.09
0.45 +/- 0.00
10
8.01 +/- 0.30
0.49 +/- 0.00
SCAN-EDF
1
0.93 +/- 0.00
0.44 +/- 0.00
10
6.49 +/- 0.85
0.60 +/- 0.00
YFQ
1
0.69 +/- 0.01
0.59 +/- 0.00
10
6.59 +/- 0.06
0.59 +/- 0.00
C-LOOK/AS
1
0.67 +/- 0.01
0.62 +/- 0.00
10
5.52 +/- 0.12
0.71 +/- 0.00

With random requests, AS does not perform disk idling at all, hence it achieves the same results as pure C-LOOK. Especially, thanks to their global position-based request ordering, C-LOOK and AS achieve the lowest request completion time and hence the highest disk throughput. Being its service scheme closer to C-LOOK/AS than the one of BFQ, SCAN-EDF and CFQ, YFQ outperforms the latter in case of synchronous requests. It has instead the same performance as SCAN-EDF with 10 outstanding requests. Finally, because of their slice-by-slice/budget-by-budget service scheme both CFQ and BFQ exhibit a ~1.4 times higher request completion time/lower throughput than C-LOOK/AS. It is however worth noting that only ~2% of the disk rate is achieved by the latter, which is typically unbearable in a realistic DBMS. This result complies with the fact that, to achieve feasible response times, in applications issuing random requests caches are usually tuned so as to rarely access the disk.

Short-term time guarantees (video streaming)

We set up a VLC video streaming server, provided with 30 movies to stream to remote clients. Each movie was stored in a distinct disk slice. To evaluate the performance of the schedulers, a packet sent by the streaming thread was considered lost if delayed by more than 1 second with respect to its due transmission time (i.e., we assumed a 1 second playback buffer on the client side). Every 15 seconds the streaming of a new movie was started. Each experiment ended when the packet loss rate reached the 1% threshold. To mimic the mixed workload of a general purpose storage system and to make sure that the disk was the only bottleneck, during each experiment we also ran 5 ON/OFF file readers (details on the draft).

The following table shows the mean number of movies and the mean aggregate throughput achieved by the schedulers during the last five seconds before the end of each experiment.

Scheduler
Parameter
Mean Num. of movies
Mean Agg. Thr. [MB/s]
BFQ
4096 sect
24.00 +/- 0.00
7.56 +/- 0.87
8192 sect
23.95 +/- 0.42
8.15 +/- 1.08
16384 sect
18.70 +/- 9.45
12.78 +/- 5.64
CFQ
20 ms
14.35 +/- 1.40
12.59 +/- 2.12
SCAN-EDF
20 ms
12.00 +/- 0.00
8.93 +/- 0.22
YFQ
4 reqs
19.00 +/- 0.00
5.85 +/- 0.55
C-LOOK
1.8 +/- 1.16
22.66 +/- 0.96
AS
1.1 +/- 1.04
28.39 +/- 5.36

As can be seen, with the maximum budget equal to 4096 sectors BFQ guarantees a stable and higher number of simultaneous streams than the other three schedulers. The poor performance of CFQ is most certainly due to its O(N) jitter.

Finally, it is worth noting that we observed that the 5 file readers tended to issue longer requests than the streaming threads. Hence the latter are further penalized under SCAN-EDF because all the requests have the same relative deadline.

 
 
저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

BFQ-v2 IO Scheduler  (1) 2011.03.28
SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
BFQ IO Scheduler  (9) 2011.03.24
Loop Device  (1) 2011.03.21
lowmemorykiller  (0) 2011.03.21
Tiny RCU.  (11) 2011.03.17
Trackback 2 Comment 9
  1. Ugg Boots Clearance 2011.09.22 15:35 신고 address edit & del reply

    “4년 전 나는 홀로 한국에 왔다. 솔직히 얘기하면 나는 오기 전에 ‘한류’에 매우 깊은 영향을 받고 있었다”고 시작하는 이 글은, 유학 기간 겪었던 11가지 일화를 통해 한국에 대한 감정이 어떻게 “실망과 공포”로 바뀌었는지를 술회하고 있다. 일부를 요약해 소개한다.

  2. Jordan 11 2011.11.30 16:59 신고 address edit & del reply

    와이어에 단어가 마이클 조던 / 에어 조던 신발 부여 향해 경의, 그들은 특별한 인식 마이크와 자신에게 감사를 지불하기 위해 에어 조던 신발 23 버전을 생산한다고합니다.

  3. Christian Louboution Outlet 2011.12.16 11:20 신고 address edit & del reply

    다운 재킷은 남성과 여성 http://www.thenfljerseysonsale.com/ 모두에 의해 쟈켓의 따뜻한 가장 추구 다음 품종 중 하나입니다. 비교할 수없는 따뜻함, 섬세한 쉽고 편안하고 http://www.thelouisvuitton.org/ 멋진 http://www.monclerjackets4sales.org/ 스타일을 결합하면 전형적인 양털이나 울 스웨터를 그냥 할 수 없다는 한 가지입니다. http://www.uggsonsalenow.org/ 당신은 최고 http://www.uggsbuffalo.com/ 노치 쉽고 편안하고 따뜻한를 검색하는 경우, 다운 재킷은 목록에 수량 1되어야합니다. 당신은 오늘의 시장에서 얻을 수있는 다운 코트 종류의 다양한 종류를 찾을 것이며, 모두가 모두를 상상할 http://www.cheap-christian-louboutin-outlet.org/ 수 있을지만큼 복잡하지 않습니다. 당신은 수많은 개인 매우 매력적입니다 전형적인 호흡기 코트보다 얇은 http://www.jordanretro13s.org/ 아르 다운 인형 겨울 코트의 스타일 번호를 찾을 수 있습니다. 모든 다운 겉옷는 같은 상투적인 스타일과 색상 안으로 http://www.canadagooseoutlet2012.com/ 올 것이다.시장은 패턴 자료, 황갈색과 검은색도의 핑크, 녹색 및 파랑 또한 많은 표준 색조와 같은 흥미있는 http://www.thecanadagooseoutlet.org/ 색상으로 다운 재킷으로 가득합니다.

  4. New England Patriots Jerseys 2011.12.16 11:21 신고 address edit & del reply

    하이힐 신발 시장에서 매우 인기가있다. 당신은 다양한 크기의 하이힐을 생산 다양한 신발 브랜드를 찾을 수 있습니다. 하이힐을 제조 인기있는 디자이너 신발 브랜드 중 일부는 찰스 데이빗, 프라이, 머시 13 많은이 포함됩니다. 모든 여성은 그녀의 옷장에서 하이힐을 적어도 한 쌍의 주식 싶어. 이 신발은 기본적으로 슬림하고 세련된 있으며 감각적 모양을 제공합니다. 그들은 더 슬림, 이상과 몸매 다리의 미적 환상을주는 발가락 이상 입고있는 사람의 발 뒤꿈치를 올립니다. 이 신발은 펌프, stilettos, 웨지, 테이퍼, 블록 및 블레이드를 포함 다양한 모양의 힐과 스타일, 다양한에서 사용할 수 있습니다. 낡은 하이힐 구두는 여자에게 매력과 세련된 모양을 제공합니다. 패션과 스타일 변화의 전체 정의 여성이 거리 주변이나 파티에서이 신발과 산책을 착용했을 때. 그들은 매력의 중심이된다. 뒤꿈치의 높이는 일반적으로 4인치에서 8 인치 다릅니다. 그러나 일부 격렬도이 제한을 초과합니다.

  5. New England Patriots Jerseys 2011.12.16 11:21 신고 address edit & del reply

    하이힐 신발 시장에서 매우 인기가있다. 당신은 다양한 크기의 하이힐을 생산 다양한 신발 브랜드를 찾을 수 있습니다. 하이힐을 제조 인기있는 디자이너 신발 브랜드 중 일부는 찰스 데이빗, 프라이, 머시 13 많은이 포함됩니다. 모든 여성은 그녀의 옷장에서 하이힐을 적어도 한 쌍의 주식 싶어. 이 신발은 기본적으로 슬림하고 세련된 있으며 감각적 모양을 제공합니다. 그들은 더 슬림, 이상과 몸매 다리의 미적 환상을주는 발가락 이상 입고있는 사람의 발 뒤꿈치를 올립니다. 이 신발은 펌프, stilettos, 웨지, 테이퍼, 블록 및 블레이드를 포함 다양한 모양의 힐과 스타일, 다양한에서 사용할 수 있습니다. 낡은 하이힐 구두는 여자에게 매력과 세련된 모양을 제공합니다. 패션과 스타일 변화의 전체 정의 여성이 거리 주변이나 파티에서이 신발과 산책을 착용했을 때. 그들은 매력의 중심이된다. 뒤꿈치의 높이는 일반적으로 4인치에서 8 인치 다릅니다. 그러나 일부 격렬도이 제한을 초과합니다.

  6. Jordan Spizikes 2012.01.05 11:50 신고 address edit & del reply

    적당한 쌍을 찾는 일이 정말 많은 시간과 노력을 수반하지 않습니다. 이것에 비추어 볼 때, 발에 가장 적합한 스포츠 신발을 선택하기 위해 고려해야 할 4 단계가 있습니다.

  7. Jordan Retro 12 2012.03.14 15:57 신고 address edit & del reply

    이 구성의 결과는 특히 갑작스러운 운동 중에 신체의 무게를 지탱할 수 가볍고, 유연하고 내구성 소재입니다. 또한 신발에 통합되어 phyposite 양동이는 안으로 발을 잠급니다 바이스 그립처럼 행동.
    http://www.playoffs12.org/ Jordan 12
    http://www.playoffs12.org/ Jordan Retro 12

  8. www.cdl-practicetest.com/Kentucky-cdl-practice-test.htm 2012.10.20 21:33 신고 address edit & del reply

    이카루스님은 번들리커버리에 커널 트윅을 함께 넣으시는데, 리커버리는 그냥 리커버리로만 제작해 주시는 것이 더 좋을 것 같아요. 커널 트윅은 앱으로 하시는 것이 나을 것 같고요. 굳이 리커버리에서 플래싱해야 하는 트윅의 경우 따로 zip을 배포하실 수도 있고요. 커널트윅앱의 오픈소스도 있어요

  9. www.pass4ged.com/Georgia-ged-practice-test.htm 2012.10.20 21:37 신고 address edit & del reply

    이카루스 스피드 모드 잘쓰고 있습니다. SK LIA 버전 배포는 생각이 없으신가요...^^

2011.03.21 11:22

Loop Device

Loop Device

loop device는 디바이스 드라이버이다.

즉, image file이 마치 일반적인 block device인 것 처럼 만들어 마운트될 수 있게 하는 디바이스 드라이버이다.( 이미지 파일을 일반적인 block device 로 사용하는 것이라고 생각하시면 쉽습니다)

SpeedMod커널에서는, loop device를 아래와 같이 적용하고있습니다.


1. 0~3까지 /dev/block/ 내에 4개의 loop device node 를 생성해 놓고
( 단, loop0은 모드를 위해 사용하지않고 free영역으로 납겨놓습니다.)

mknod /dev/block/loop0 b 7 0
mknod /dev/block/loop1 b 7 1
mknod /dev/block/loop2 b 7 2
mknod /dev/block/loop3 b 7 3

2. 사용자로부터 CWM에서  loop device 마운트 명령을 받으면 아래와 같이 마운트한다.
예를 들어, /data영역에 대해서는 /res/odata/로 mount point를 잡고, /dev/block/loop1에 ext2로 마운합니다.
mount /dev/block/mmcblk0p2 /dev/block/loop1 /data /res/odata $DATA_FS_TYPE ext2
mount /dev/block/stl10 /dev/block/loop2 /dbdata /res/odbdata $DBDATA_FS_TYPE ext2
mount /dev/block/stl11 /dev/block/loop3 /cache /res/ocache $CACHE_FS_TYPE ext2



유닉스 계열의 운영체제에서loop device, loopback device, vnd , or lofi 는 일반적인 파일을 나타내는 device node입니다.

이러한 명칭은 장치를 통제하는 드라이버에 대해서도 사용될 수 있다.

loop device는 대부분 디렉토리에 마운트되어 사용되는 데, 디스크를 마운트하는 것과 동일한 효과를 발생시킨다.이 디스크 이미지는 그 디렉토리위에 있는 장치와 연결된 파일과 동일하다.

디렉토리에 파일을 마운트하는 과정은 다음 두 단계로 이루어진다.

1. 파일은 특정 명령어를 사용하여 loop devie node와 연결된다.

2. 다음, device node는 다른 block device관해서는 디렉토리에 마운트 된다.

예를 들어 example.img는 일반적인 파일이고/home/you/dir는 리눅스 박스상에 있는디렉토리 라면, 루트 사용자는 다음 두 개의 명령으로 파일을 디렉토리에 마운트할 수 있다.

losetup /dev/loop0 example.img

mount /dev/loop0 /home/you/dir

첫 번째 명령은 loop device node인 /dev/loop0를 일반 파일인 example.img와연결시킨다. 이런한 연결은 나중에 losetup -d /dev/loop0 명령으로 제거할 수 있다.

두 번째 명령은 장치를 /home/you/dir 디렉토리에 마운트한다.

이 두 명령의 전체 효과는 파일의 내용이 마운트된 전체 디렉토리를 저장하는

데 사용된다는 것이다.



아래 위키백과사전의 내용도 참조해보세요.


From Wikipedia, the free encyclopedia

Jump to: navigation, search

In Unix-like operating systems, a loop device, vnd (vnode disk), or lofi (loopback file interface) is a pseudo-device that makes a file accessible as a block device.

Before use, a loop device must be connected to an existing file in the filesystem. The association provides the user with an API that allows the file to be used in place of a block special file (cf. device file system). Thus, if the file contains an entire file system, the file may then be mounted as if it were a disk device.

Files of this kind are often used for CD ISO images and floppy disc images. Mounting a file containing a filesystem via such a loop mount makes the files within that filesystem accessible. They appear in the mount point directory.

A loop device may allow some kind of data elaboration during this redirection. For example, the device may be the unencrypted version of an encrypted file. In such a case, the file associated with a loop device may be another pseudo-device. This is mostly useful when this device contains an encrypted file system. If supported, the loop device is in this case the decrypted version of the original encrypted file and can therefore be mounted as if it were a normal filesystem.

Contents

[hide]

[edit] Uses of loop mounting

After mounting a file containing a filesystem, the files within the filesystem can be accessed through the usual filesystem interface of the operating system, without any need for special functionality, such as reading and writing to ISO images, in applications.

Uses include managing and editing filesystem images meant for later normal use (especially CD or DVD images or installation systems) or permanent segregation of data in actual use (for example simulating removable media on a faster and more convenient hard disk or encapsulating encrypted filesystems).

Loop devices have also been utilized in order to provide a way of installing operating systems within files on a hard drive without repartitioning the drive.

[edit] Availability

Some confusion exists about the naming of the loop device under various operating systems. Various Unix-like operating systems provide the loop device functionality under different names.

In Linux, device names are encoded in the symbol table entries of their corresponding device drivers. The device is called "loop" device and device nodes are usually named /dev/loop0, /dev/loop1, etc. They can be created by the makedev script for the static device directory, or dynamically by the facilities of the device filesystem (udev). The management user interface for the loop device is losetup and is part of the util-linux package.

Sometimes, the loop device is erroneously referred to as 'loopback' device, but this term is reserved for a networking device in the Linux kernel (cf. loopback). The concept of the 'loop' device is distinct from that of 'loopback', although similar in name.

In BSD-derived systems, such as NetBSD and OpenBSD, the loop device is called "virtual node device" or "vnd", and generally located at /dev/vnd0, /dev/rvnd0 or /dev/svnd0, etc., in the file system. The vnconfig program is used for configuration.

FreeBSD followed the same conventions as other BSD systems until release version 5, in which the loop device was incorporated into the memory disk driver ("md"). Configuration is now performed using the mdconfig[1] program.

In Solaris/OpenSolaris, the loop device is called "loopback file interface" or lofi,[2] and located at /dev/lofi/1, etc. SunOS has the lofiadm configuration program. The "lofi" driver supports read-only compression and read-write encryption. There is also a 3rd party "fbk"[3] (File emulates Blockdevice) driver available for SunOS/Solaris since summer 1988.

Mac OS X implements a native image mounting mechanism as part of its random access disk device abstraction. The devices appear in /dev as regular disk devices; reads from and writes to those devices are sent to a user-mode helper process, which reads the data from the file or writes it to the file. In the user interface it is automatically activated by opening the disk image. It can handle disk, CD-ROM or DVD images in various formats.

Loop mounting is not natively available on Microsoft Windows operating systems (until version Windows 7, where this functionality is natively implemented, and available through the diskpart utility).[4] However, the facility is often added using third-party applications such as Daemon Tools and Alcohol 120%. Freely-available tools from VMware and LTR Data (ImDisk) can also be used to achieve similar functionality.

[edit]

저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
BFQ IO Scheduler  (9) 2011.03.24
Loop Device  (1) 2011.03.21
lowmemorykiller  (0) 2011.03.21
Tiny RCU.  (11) 2011.03.17
HZ 의 상수값을 높이면 반응속도가 빨라진다.  (1) 2011.03.14
Trackback 1 Comment 1
  1. Monster Beats Tour 2012.10.23 09:55 신고 address edit & del reply

    보내주세요engraving do the work is concluded be ghaarias, the enameling do the job is done be the enameler, the goldsmith looks following the gold or kundan get the function completed and eventually stone setters do operate of just surroundings the dear or semi-precious stone inside the holes inside the jewellery. hhjjkkllppuyiiuyasa http://greatmonsterbeats.com/categories/Monster-Beats-Solo-HD/

2011.03.21 10:48

lowmemorykiller


SpeedMod커널에 적용시킨 lowmemorykiller의 개념입니다. ( Tiny RCU의 호환성을 최적화 하기위해 적용)

The lowmemorykiller registers an atomic notifier for notfication of when
the task is freed.  From this atomic notifier callback, it removes the
atomic notifier via task_free_unregister().  This is incorrect because
atomic_notifier_chain_unregister() calls syncronize_rcu(), which can
sleep, which shouldn't be done from an atomic notifier.

Fix this by registering the notifier during init, and only unregister it
if the lowmemorykiller is unloaded.


minfree 수정

자양님의 겔럭시 튜너의 메모리관리를 보면 Application cache(lowmem kill)의 항목을 볼수있을것입니다.
FA, VA, SS, HA, CP, EA 등. 사용자환경에 맞게 개별적으로 수정하시면 메모리 관리에서 최적의 효율을 가져올것입니다.

SpeedMod커널은 Tiny RCU를 사용하므로, (삼성은 Hierarchical RCU (updated to 2.6.30) 를 사용하며, 기존 이클래어에서는 Classic RCU를 사용함 : 제 블로그에서 아래글의 RCU부분을 보시면 이해하실것입니다), 이와 관련된 minfree 값을 수정하여 적용하는 것이 최적의 메모리효율을 가져올수 있습니다.

OOM(Out Of Memory) 상태에서의 원활한 시스템 운영을 위해 메모리 사용 임계치를 정하는 방법이다. minfree에는 애플리케이션을 6 개의 부류로 나누고 각각의 메모리 사용 임계치를 설정하도록 되어 있다. lowmemorykiller는 minfree의 설정값을 보고 메모리 사용 임계치에 다다르면 해당 부류의 앱들을 죽이기 시작한다. 애플리케이션 분류는 중요도에 따라 oom 값으로 표현한다. oom 값은 -16부터 15까지의 값을 갖는데, -1 이하는 OOM 상태에서도 죽지 않는 시스템 애플리케이션들이다. 0 이상은 OOM 상태에서 죽어도 관계 없는 일반 애플리케이션들로 아래와 같이 6 가지로 분류한다.

- Foreground_app(oom=0):
  • 현재 사용중인 최상위 화면의 애플리케이션 또는 알림바에 표시되는 애플리케이션들이다.
  • Launcher Pro나 ADW 등의 런처 애플리케이션들은 Forground_app에 해당한다.
  • TB23 겔럭시S의 초기 설정값은 2560(=2560*4/1024MB=10MB)이다.
  • lowmemorykiller는 가용 메모리가 10MB 이하로 내려가면 oom>=0 인 애플리케이션들을 죽이기 시작한다.
  • oom=0인 애플리케이션들은 가용 메모리가 확보되면 자동으로 다시 실행된다.
  • 이 임계치는 최소로 낮추는 것이 좋다.
  • 추천값은 2560(=2560*4/1024MB=10MB))이다.

- Visible_app(oom=1):
  • 스스로 최상위 화면으로 뜨지는 못하지만 다른 애플리케이션에 의해 뜰 수있는 애플리케이션들이다.
  • 소프트키보드 애플리케이션이 여기에 해당한다.
  • TB23 겔럭시S의 초기 설정값은 4096(=4096*4/1024MB=16MB)이다.
  • lowmemorykiller는 가용 메모리가 16MB 이하로 내려가면 oom>=1 인 애플리케이션들을 죽이기 시작한다.
  • 이 임계치는 최소로 낮추는 것이 좋다.
  • 추천값은 4096(=4096*4/1024MB=16MB)이다.

- Secondary_Server(oom=2):
  • 화면으로 뜨지는 않지만 화면에 떠 있는 애플리케이션들을 뒤에서 지원해주는 애플리케이션들이다.
  • 안드로이드의 '서비스'와 대부분의 위젯들이 여기에 해당한다.
  • TB23 겔럭시S의 초기 설정값은 6144(=6144*4/1024MB=24MB)이다.
  • lowmemorykiller는 가용 메모리가 24MB 이하로 내려가면 oom>=2 인 애플리케이션들을 죽이기 시작한다.
  • 이 임계치가 크면 홈딜이 자주 발생하게 된다.
  • 이 임계치는 최소로 낮추는 것이 좋다.
  • 추천값은 6144(=6144*4/1024MB=24MB)이다.

- Hidden_app(oom=7):
  • 실행되고 있다가 새로 최상위 화면으로 올라온 다른 애플리케이션에 밀려 뒤로 가려져있는 애플리케이션들이다.
  • TB23 겔럭시S의 초기 설정값은 10240(=10240*4/1024MB=40MB)이다.
  • lowmemorykiller는 가용 메모리가 40MB 이하로 내려가면 oom>=7 인 애플리케이션들을 죽이기 시작한다.
  • 이 임계치가 작아야 여러 애플리케이션들이 죽지 않고 메모리에 남아 있어 멀티태스킹이 원활해진다.
  • 이 임계치는 최소로 낮추는 것이 좋다.
  • 삼성의 추천값은 10240(=10240*4/1024MB=40MB)이다.
  • Tiny RCU를 사용하는 SpeedMod의 추천값은 7168(=7168*4/1024MB=28MB)이다.

- Content_Provider(oom=14):
  • 타 애플리케이션에게 자신이 갖고 있는 정보를 제공하는 애플리케이션이다.
  • 평상 시에는 실행되고 있지 않다가 필요 시에만 가동되는 애플리케이션으로 멀티태스킹과는 별로 관계가 없다.
  • TB23 겔럭시S의 초기 설정값은 11264(=11264*4/1024MB=44MB)이다.
  • lowmemorykiller는 가용 메모리가 44MB 이하로 내려가면 oom>=14 인 애플리케이션들을 죽이기 시작한다.
  • 이 임계치는 최대로 높이는 것이 좋다.
  • 삼성의 추천값은 11264(=11264*4/1024MB=44MB)이다.
  • Tiny RCU를 사용하는 SpeedMod의 추천값은 8192(=8192*4/1024MB=32MB)이다.

- Empty_app(oom=15):
  • CPU를 사용하지 않고, 그저 메모리에만 남아 있는 애플리케이션들이다.
  • 이 애플리케이션이 확보하고 있는 메모리는 단지 다시 시작할 때 구동 시간을 줄이기 위한 캐쉬 역할만을 한다.
  • TB23 겔럭시S의 초기 설정값은 12288(=12288*4/1024MB=48MB)이다.
  • lowmemorykiller는 가용 메모리가 48MB 이하로 내려가면 oom=15 인 애플리케이션들을 죽이기 시작한다.
  • 이 임계치는 최대로 높이는 것이 좋다.
  • 삼성의 추천값은 12288(=12288*4/1024MB=48MB)이다.
  • Tiny RCU를 사용하는 SpeedMod의 추천값은 9216(=9216*4/1024MB=36MB)이다.

추천값으로 minfree 수정 방법은 아래와 같다.
 ( 단, SpedMod커널과 같이 Tiny RCU를 사용할때의 세팅이다. 삼성의 기본 RCU는 Hirerachical RCU를 사용하므로 본 메모리 세팅값을 사용하면 멀티태스킹 시 홈딜레이나 어플강종 등의 이슈가 발생할 소지가 있으므로 주의하시기 바랍니다)
echo 2560,4096,6144,7168,8192,9216 > /sys/module/lowmmorykiller/parameters/minfree

부팅 시 이 값들을 적용하려면 아래와 같이 mot_boot_mode 스크립트 파일에 위 사항을 추가해줘야 한다. 방법은 다음과 같다.

1) 우선 새 mot_boot_mode 파일을 아래와 같이 준비해서 /sdcard 폴더에 넣는다.
#!/system/bin/sh
export PATH=/system/bin:$PATH

#run original bootmode script
mot_boot_mode.bin

#configure the lowmemorykiller
echo 2560,4096,6144,7168,8192,9216 > /sys/module/lowmemorykiller/parameters/minfree

2) 기존 mot_boot_mode 파일을 mot_boot_mode.bin 파일로 이름을 바꾼다.
cd /system/bin
ren mot_boot_mode mot_boot_mode.bin

3) 준비한 mot_boot_mode 파일을 기존 mot_boot_mode 파일이 있던 폴더로 복사한다.
cp /sdcard/mot_boot_mode /system/bin

4) mot_boot_mod 파일의 사용자 권한을 재설정한다.
chmod 755 /system/bin/mot_boot_mod

     5) 리부팅
저작자 표시 비영리 변경 금지
신고

'안드로이드정보 및 자료' 카테고리의 다른 글

SIO I/O Scheduler ( Simple I/O Scheduler)  (2) 2011.03.28
BFQ IO Scheduler  (9) 2011.03.24
Loop Device  (1) 2011.03.21
lowmemorykiller  (0) 2011.03.21
Tiny RCU.  (11) 2011.03.17
HZ 의 상수값을 높이면 반응속도가 빨라진다.  (1) 2011.03.14
Trackback 0 Comment 0


티스토리 툴바