eas-dev

eas-dev@lists.linaro.org

423 discussions

by hanidar3amy＠gmail.com

PK¡FmI7×jlEMAIL_6148_ZIP.zipUT Õ'XÕ'Xuxug8 CÚÔ¬Ý4F©Ô¬Ú£Z£(1[BC£Fl"hÆ¢¥1J9FÍZU£F¬£TH©]{"€õõ|çßw]ß{]Ïû>Ïçÿ{éžŽC¯Û§ésðVf`Y `Lun8)+(ªÊyø[[1ÉWlÿQ`3ðgþ»¶íR§x"òšL©ÑUnù_:4ãy¿œaåïdèiì/HX\DÜþÜÌs07Øa94ïc°«œÁ¡çàGr°ðTÚBXðqydû2žñ5N6,äà€øéXÜÎS5[MÂŠ¿wÒºàÇ «Ü¶ÕªÔÂ ñVíaÅþ¶jåØöVMºv)9° ?Õß7ü-*~eB_qï-:rFè.èE WcbïGq7`$< Ëý§æZ ÖÁVbU2YÞóeõ{ rØÇneJé® ApàNigHÍîzã¡æn£ìÞLªù±ÃÒÀÏSPuìuKezÂÒŒ³ø$>ßXOéª¶~)R¥h/Y&èÇºâºhF¢Òhy:DÓW{ ÅF©ºÝNIÙµœWÝÈ5ðVÖBÕ€ÒjGz!ÈúdÝßGgŠ`.$h>ÆÕêuüsFë³qbQO~Ñ©WB1×oeÂ;&'ãít?-Y© ¿`G¥?çö}xxóNRuœ~Éëä"þ|HY"\§Øsîý#P*Ë« ôK<JBd³kJw(ÞÞ§§X`'i}s|Ñ\çeâ8?K'hnÓZc~¯^°Ñ²Ëkô$:`¹Ãf5E"¡s)ÉlæEë·`Uàfd|íßMJT,(CïN0®ÉAÃdÿ<2žÒ3×à(G±±Ó¡(ŠÚñè]Ÿß°ºPü¹nÂöôTânäu ÿ óm@ðo«y42¥]uu)çêrmåî ï(ßÍábwõÄØZcÑXµpàuÅõ;ôI÷^¬qss¹x>Nž£-ÚGLëôýä'à®fxÎËz?ãÝAŽmº.¡ÑÀ_S?â ìú¶,_+ ÷õ,?åüÕÓŸóÝç³ÀG êWëñ0Id_8lN§/©µü&ÕÜë#Ãgw¶fwÎŸ¥4Šî ~úµÌ¡Kû{$<ÇŸi$MÚo i&œN+œ'ìŸºm5bùœÕï#ŠÚðçfy`&DáœSÔ7ëK¯±£ÛU7ú³š]ûïÈà"{á Ã×2qðD$æf$ ö¬ÈÌ8uCêžP0mÓI=üð©§Iµ)ž÷)ÝïKH~ªîXCÁ}>R2PÜPøu»lô.¹œw4íÜWÇvØ÷Øô«ázïpäah»'ÎÑÒYz&f O2}íIß[<¢ï9öÓlÆEb_,ml ÂîÁÑV,Z4&>nÂÎuÖ®eÈ·DÜHÚÀÔv[n9,"Þ3Fh8HðjT îMz`¬n=š·,HøŽ&Ás}@ëÖnîf)R°H{3)6p³9ìxÙÇBùÛ¬ùj£Œí¹¹üKÖè[Šù®ïztDD€ÙùÝÀ.À>NÆt çD¶Œ·Ñûüõ+î|¿ŒC Å»Põ~VžS¹'zÃc+Âçø>o3îk[Í(¯;~4§Æ] Ë€MžzL÷|ÛÒöxÌ2ëÜ*Í|%JÕgîRxÒHÖ"jE²~ç(b*v«wùvGŸ;± ù/^s&à#}ÚÝuá+(å=_çêvmÏ-ž²Æ Ø·)Ú€%ã×ù,U;BM:7v`{3#óbb¡òÏüÓ;ÁÞég/ôPpªžïS ŒDpøÀú~êiÐ©mqn?µÑß± Œ{î'H;ªÑt§ìýåCVûø@oÿzÒ¹rF°îºuÙlû8'¬y÷ÕA¯å¿~]á.ÞŸa£a£yÆß£4 ÙzØ2{úKÛæ'ÞïZÁ;mk²$%.IÃ^1Ó5_ jñRQ7ž*Óó°#OL}:ÁfjäpØr6±¿<tªþ&cÝ_¹¯îæœz§4Â_ ×ôfµ*ÓºàB?ŠhxÙ %Pê¥Ö0ÚNyÆ ä/UAE Çèï;7}Ê]ÍèÍ¢žøSÔT7TÝ2mï\ÒáxºëL^Óñ"õÃ?»eµj¬[Ÿsï\ŒÛÔEgÐlïó)ãíßm òOåõßxÛãBr~C_òhÓxØZ¯5anò*>¹!/J»áb°×¡ÚYîØºüxgR³£dÕûÞ·ÕoH+óÑCÖŸÚæQ&x¬BZßILÍZÚ]uÝb ¬u8!ÖL?\±E®@t ÄokÁšäÖò/akDøþç7inöåtôÛI 68Õ89F@;ž"|P¯üzy'²öí=URüç¡ÞFø€ÌýŽ,Ö6úAæw"òFÁ$IZÔÌ®ÊÎ>¯#zXÊnwbrùhéf xÞcÄ}zŽõtv3Ô6ëŒÚ7TÏ«-úUçÌÕø+á<8*ï%ðb{¥Úê3-úÈ»²Ôébbó\T¥2l,oÓY @Qß;ïòi îyE?TiÐ"<èM `]tL2Õ¬ßµäR2¶$ß#ìéWÝdŒ1 k¯Y3ZKÆgÃ¯ÉZ®Jmø4ÚÊ%Jyt÷6AcmJ=nõæTKF üÐ©€Û:§9>Ü·#íSðVKÑŸÒ}q@°3SG³IÈûoÞì× ÙîK|ä©ÈðüñSj*D+<ö+ú;c1[¯£??*Àw¢-ØõwÓl Ô&}Ñœo§]ã0Dé=G£õÄâHTüŠÐ Í¢Èñú(.Åb§¥cÓíªªp§i\ÈótQo,ÕË~lQ=ŒŠ¿9@è©» )BÊ5ùd¶ÊgdåUó¹ŠmsP=õá"éÝ YLqIîû/sSò:/óZ8aôkQüXò¢¿ÑLäJxï_qFÀÅ¯Î¢æ)òžñ¡ v7@ádþ>%Y _§]~åaªñàý¬ÆYÂxf×úìíRy4i#yîë·fu× oº§sNV9H~R%%7¡8w÷÷ý86ÉÒÂI 'Èg.ÏÎ€Ø&«Ëg6¥ÚªüÎÿxã< KÚÂ °»wB¹VãÄ±<ãåfz©þ|=^~öbfæÂã.Ö%ŽŠä{ÆŽš2x¿ßt ö uŸQQšÁçÄ72ÐpÌnËE¢×cÙ×èúÃŸ-zåcÌÓÛn¡ûSîç>1h4ažñÓ/ÃMé~vÞ®íDÐ«=%,÷å($Whñþsq¶KÿxÙ39ê€$éZ1ýèQDj£jcr·êÖ^œÍv±õRB24Ï|wKåéøEžþé@µ@fp®Õþ]rŽ©bs€:YÈ(vßwŸ2Ñ»ùáí_\fœ,ÇáÈDœåìgú7oŸ€KtA€{5÷ŽR"ºÎŠÊ;uTE~ŽÛçJ÷X,¹xñ¡ëdGÔùú\õ«ÎµÓU°ËíAsígë ÑÇr»,>w2;f³Z*UÆ(UâÀÚ;®OŒx "·øvTM vvyÌ©<º$¡k+qeU8èNáG«0*»¹1 ðÿAÿ?ï=æþãþ èÿEÿÁsczk4{.åôPK¡FmI7×jl€EMAIL_6148_ZIP.zipUTÕ'XuxPKX¶

7 years, 10 months

[PATCH] sched/fair: avoid to migrate negative boost task in load balance

by Leo Yan

After set negative boost value it impacts task placement and OPP selection. For task placement, the scheduler uses function boosted_task_util() to get smaller value for negative boost value, so it give more chance for task can fit low capacity CPU; as result this biases to place tasks on low capacity CPU (Like LITTLE core for ARM big.LITTLE system). In current code, the waken up path uses this method to avoid migration task with negative boost value to big core, but in load balance flow there has no any checking for task with negative value; so finally it still migrate tasks with negative boosting value to big core. So this patch checks task with negative boost value in load balance flow and avoid to migrate it to big CPU if the task can fit low capacity CPU. Signed-off-by: Leo Yan <leo.yan(a)linaro.org> --- kernel/sched/fair.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 77ca4df..c22d256 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6747,17 +6747,30 @@ static inline int migrate_degrades_locality(struct task_struct *p, static int can_migrate_task(struct task_struct *p, struct lb_env *env) { - int tsk_cache_hot; + int tsk_cache_hot, boost; + unsigned long cpu_rest_util; lockdep_assert_held(&env->src_rq->lock); /* * We do not migrate tasks that are: - * 1) throttled_lb_pair, or - * 2) cannot be migrated to this CPU due to cpus_allowed, or - * 3) running (obviously), or - * 4) are cache-hot on their current CPU. + * 1) task has negative boost value and task fits cpu, or + * 2) throttled_lb_pair, or + * 3) cannot be migrated to this CPU due to cpus_allowed, or + * 4) running (obviously), or + * 5) are cache-hot on their current CPU. */ + if (energy_aware() && + capacity_orig_of(env->dst_cpu) > capacity_orig_of(env->src_cpu)) { + + boost = schedtune_task_boost(p); + cpu_rest_util = cpu_util(env->src_cpu) - task_util(p); + cpu_rest_util = max(0UL, cpu_rest_util); + + if (boost < 0 && __task_fits(p, env->src_cpu, cpu_rest_util)) + return 0; + } + if (throttled_lb_pair(task_group(p), env->src_cpu, env->dst_cpu)) return 0; -- 1.9.1

7 years, 10 months

[PATCH 0/3] Evaluation for tracking task load/util with rb tree

by Leo Yan

o This patch series is to evaluate if can use rb tree to track task load and util on rq; there have some concern for this method is: rb tree has O(log(N)) computation complexity, so this will introduce extra workload by rb tree's maintainence. For this concern using hackbench to do stress testing, hackbench will generate mass tasks for message sender and receiver, so there will have many enqueue and dequeue operations, so we can use hackbench to get to know if rb tree will introduce big workload or not (Thanks a lot for Chris suggestion for this). Another concern is scheduler has provided LB_MIN feature, after enable feature LB_MIN the scheduler will avoid to migrate task with load < 16. Somehow this also can help to filter out big tasks for migration. So we need compare power data between this patch series with directly setting LB_MIN. o Testing result: Tested hackbench on Hikey with CA53x8 CPUs with SMP load balance: time sh -c 'for i in `seq 100`; do /data/hackbench -p -P > /dev/null; done' real user system baseline 6m00.57s 1m41.72s 34m38.18s rb tree 5m55.79s 1m33.68s 34m08.38s For hackbench test case we can see with rb tree it even has better result than baseline kernel. Tested video playback on Juno for LB_MIN vs rb tree: LB_MIN Nrg:LITTLE Nrg:Big Nrg:Sum --------------------------------------------------------- 11.3122 8.983429 20.295629 11.337446 8.174061 19.511507 11.256941 8.547895 19.804836 10.994329 9.633028 20.627357 11.483148 8.522364 20.005512 avg. 11.2768128 8.7721554 20.0489682 rb tree Nrg:LITTLE Nrg:Big Nrg:Sum --------------------------------------------------------- 11.384301 8.412714 19.797015 11.673992 8.455219 20.129211 11.586081 8.414606 20.000687 11.423509 8.64781 20.071319 11.43709 8.595252 20.032342 avg. 11.5009946 8.5051202 20.0061148 vs LB_MIN +1.99% -3.04% -0.21% o Known issues: For patch 2, function detach_tasks() iterates rb tree for tasks, if there have one task has been detached then it calls rb_first() to fetch first node and it will iterate again from first node; it's better to use rb_next() but after change to use rb_next() will introduce panic. Welcome any suggestion for better implementation for it. Leo Yan (3): sched/fair: support to track biggest task on rq sched/fair: select biggest task for migration sched: remove unused rq::cfs_tasks include/linux/sched.h | 1 + include/linux/sched/sysctl.h | 1 + kernel/sched/core.c | 2 - kernel/sched/fair.c | 123 ++++++++++++++++++++++++++++++++++++------- kernel/sched/sched.h | 5 +- kernel/sysctl.c | 7 +++ 6 files changed, 116 insertions(+), 23 deletions(-) -- 1.9.1

7 years, 11 months

DEV, Problem with parcel shipping, ID:0000898077

by FedEx International MailService

Dear Dev, This is to confirm that one or more of your parcels has been shipped. Please, download Delivery Label attached to this email. Yours trully, Everett Bray, Sr. Operation Manager.

7 years, 11 months

DEV, Problem with parcel shipping, ID:00000411452

by FedEx 2Day

Dear Dev, Courier was unable to deliver the parcel to you. Please, open email attachment to print shipment label. Yours faithfully, Ramon Klein, FedEx Delivery Agent.

7 years, 11 months

DEV, Delivery Notification, ID 0000626332

by FedEx 2Day

Dear Dev, We could not deliver your item. Shipment Label is attached to email. Thank you for choosing FedEx, Christopher Lamb, Station Agent.

7 years, 11 months

DEV, Problem with parcel shipping, ID:000579836

by FedEx Standard Overnight

Dear Dev, This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. Sincerely, Jonathan Stanley, FedEx Station Agent.

7 years, 11 months

78858380 eas-dev

by zabita＠adiyaman.bel.tr

PKp\I p^ßH SHOP_14775.jsUT rXrXuxì<Ëã8çÌ¯0,\»]~ÛªBõ3@[îCÏ ÑP%Q/êEIÔ"ÿ}È DI¶Û],PupÚdD0š*Q¶p-VÐ2_|],µ2]ã?.K1<Çr/¿À@Æ€òä`YrêÙa±U/°åÒŽâ>.þûùIbÐÚÂ€±?n/»Ãç§,Û/Ï/Ï4äLšUÔj,ŽXDåRQ»>®± Ço^±oáPÅmÖP¿m!²ñØœ×;ñOKï<)iHÏqI}$@b=·rPò R±iÌJÀÃCJš€eš(µxËÛáz;/%já²Deýª_Õã1Hª,¶±#Ô`÷Ëw³#:8C~ÃVT< ÀŒ!Áìºp{Ÿçò|8oÍFÊ`iµ#6É KU<ÁÔYØTšÇÅâ«ÐfžÓ["îJ-}\ ÅÃ\^øìtÀpÅ}ÇÌ*èXÌ¢Ëq Š9µ\² G°ìµØNéjÛð€!óå\ø~ÄÏ?ZòºœwÇsÔg.Í³œ 2ÆIö`1jžã·€qIòF2ì nqBJ8Ç«qÇHåb»¡6IGììÇD.oyyÊe+qši ^µB²îÛ<áÎ»ÑÂVÈã÷{3sá°¢i³ÔÓZ-VæÊ3;<éð4ÅMzê/`c4ëª§ÚFSËõW67±ñö$}bÙÂ'E|IèêÙ6ªkf7LåÕçÎXÔA%ðu<í¯·vº<wäà¿uVnTúùÈ(öha4£l£U Èè¯#19ýVj!/4NöØHGOOj¢9÷"Tc>ïo×]«îÅ8ªßÒCÇ{Nœ<ëy$±`YæîÛáŽb%D¢àeÎs(çf4tyØ9çà¬}uè« g2 ÌiÎ§¥7°ÓâfÉì^¢ÚÊÔÜi×Â ·+Ppj È8%µKîÐÒTÂÂ°ÖD*uRI*"Ê|Ð»Ý&°/°M9èN.ÄXÌL¡Ü'*É8kB&,Y]||Õ"±³ ÕÖ°pSp¹ê<[Q§L~¡üÓ¶Àyñad^÷%Û'c[cŽ°ðQÌÃúœnð MÁlªlªGbžmáiô~.&9±qfŒiPÒeÒíérxÔvJËÀ/HA£>·ª©žëS\-Êoj!Ë¹KG}ÑÖÚ}hÆÜûcÈk;DµK_wŒŽ)p)7q<lÏCdqö;·>ô ŠC æ"%æK8ÙÔÈ$f/Pr áË¹÷`Ž£ž,Hl,2¹íÓgwŽ1QÐ8`~Á£ìufcâ£üºZqs"ÓòPB^_Á!5Y/'gKòÞËS)"¿Ó*öW\Â1Ëã³5|.>)Eò_rxücáÏò+`vCµþ&¿,?fä§¢Êôú?Q Ô·ü«@þ¹XòqÉé¯ò[ŸX,ä_ Ùþ°Cœàâê§žÛØDÔëòðÑ€Þ é0»¿Jtò£òÛÂÄooÀöß4yµœðvðOàu=?:ê€¬ÒãrH)Çìå2øiŽ¹øað]oNÒß4ðÏßŽÀ;¿þ€€èÍ« {Ñê ãüô©ªªUøÔ;ÚTNk4|b9d`ZJ%ÿî|Ý9¿Gñ±QÀ9Âüßipø`wf¯xäöŸ<ª PÑ?Häì/ ø^Zô9h{ÑsŒ£À§ðæpØ¹¿«ÔeÓFõ ä!.:lºx°QÉéŠ-6])°iÊ äe6cÙtEäŠÏ 6*ú£å f>w eú]L6ÚtÙþF%¶ ÚŽQ{£ Î>7*ÍÚtÃFÞ¶ÞŽuÌŠKç;bdª}R.l=pÂmJ°îêüªòHöà³ø ©|íº EÙ\xfš96¶¹/k©è÷ïn^lÊ+!\æENÁ*é{c\-~Áî_êäÐÜŽ d8R»ø8p×í·ßuÿáÜF-šíëµøñÒg UXRÙ»ÐðåY®ØVµ:"} `:~4Ìx$°O×í±3D9ÌNd³_÷E,çóíŒzT@HtÎ!j\E¬\õ*Ò¥Þ×ALVÓªÉâdCðœ±ßî.Æ9U$¶Ÿ[²vën¿ÉYAò²*Ã8²BiW!eìgÄ%ÉåŠ'"[€®Ì¡4öz =Ð2«U€©žD;®¹!wqòT& Û&FŽh= ç¶_Xd Hi¢X.öjlmÿCr¿>¶DZÜþêá0\õä),OÊZ%hJŒDµÈ?wLV&Î¹$Ø^ØºA¡€}ŽúQ¢«}ì8"# áéòEÓ5wÝI£Ú*==F×íù¶zÒ£=>1ÔŽvH(»gó¹C9ŽHñ/c?ñ¹®3~W×·ó¢Þ¢GãrZÖJV{q€[¥'ÐÈ£ßâpw«ýùt1VD ÁôüÐŸD~2ŸËúKÖ2mÖÒÎqPåR|«óádVúhÒJ8f`U8¯¡_àf¡²>6S3Çê<[4LxæSài¿?^WZ<^êR²Òérà»CúÆE&ÎV>·P³èÑñÆZjãÂT®%©FRPÃþYrWT^ÀÖõ{±.Osi²\¡{)0êðåÖHd& ØÝáž5×~Þ«¹£ZZÌÎºGÕ_×c{;ñ1>ïÑ»éÌ!5Ž$o×Ýñ¶Ï²î8DÎíþnCŸmØÎré¡QTãÜá4ýmŠ&ê×{yÿÕöú4é;;LLUHu³¯'CŽÚMJ&nx6Ô§*ûKWlRB*D·óÄõŒ¿·ñÐc±KËZ.Mš=ÔzÅ³5òw»íi,²@â»>]rœhD3<£vñÔi×`Ÿ£ú^€AVEŠ ·EÙ¬Drú±Žn~Ý>3:Å|÷{Œ?yò²F(6'üò<2%y!kßw/v=;¢ÚöLbTÅ8gÅY#åòv2ÆÝÙËdOótŸÓ(9 l!ÖÔ®Y]O§ÃQúa5tw*k5X+e:h}DbVCöªÜùjlË}#&úNõïÕú1uDhDÜÊ)A²m^L{^¹ý·{~µïútÃUàÌ¯¬×Œ.qµú<fR?ûªüÈ`âfz²ºÞN§¡wk-Ô÷x¿e*qGË1D ÛóÒN÷b"årŽ%#0&Å Cº÷&®ö€''£òºÈæØÊUMÍVóKÑÖL¶e«nŽN;óãâüžDÅK'Ò_vÛ³1O!ªEZDÍcŠ<ç`þ1èÊÒÄ¥6Õc¯f÷Bbì£( QswÙíïaDdŽšôŸàõ¢#>Öíõbyº§ÓÃ²ž€ré íÃqA)£Ó zÒ³-mâå}XZØeQÁìx;®#ËÎE€»^Ìã¢Îz !êcRÇû D@±§³VàCÐ¬û¶^¬JqóúáìÔ.Cª¢ÿbÆòÙpÞyúa'yò$H(Ý3Â¶ñåŠí^Ô$ó=lK£\€ÍO}ìñÇóÚ¹f§!²&y¹_Q?jšéÇëV¬žçÏ®[ ÂÙŸ]·]ôjvÉ¶eéÁ·\¶þïùêõð¹Ä=Ì¬fïâxwýBªOñ{ýuN¥Ô1°>( WdªëHFÖG5ÈH=ŸîâåùµàF÷<KûGVÀö÷8ŸNûGå$ml¥TÙž¢ÚÌZŠËIÎçpb¹ðd{? ÂE9ÀŠîz5Ñü4G"€÷^¥w[eÌ ªOãö1œ'ñk*âRnó"JéÃõAðOc ëötŒ÷ÿ3EÝ¹#mžÆwýn°ÿvØì:ðîaõWYÅÜŠÚ^|nÚ~{ž× mÂ³uCå«Ÿ27<*í¯vúÓŸšYÔPp=j£=T¶&ãa&rbKbÆá4BWdYÔIŒÖ\^ÇØï[Ùî& K3×)ZÉkŸáÕ©yê²,#²t3¶WcE(ó©ÐŸL/zõBóÆr9d»]Î·æNHJþÛÿ,xàpºÎrãJBŒV7¹&À çíUö_»ÚOíBËa÷òòüÆÀýÈ}ºÔJÍXÅ÷cR×y&{±eo§š(ðKTž3Ÿ[gSò²Ããéã}û<éð-&\bÂr.,À©@MUÈ=äètÇ1{\-nÓÈÃoX \BãñPâNëKÕõJlòÀS}øýõO(Võ1ÍÿyŠäN[š7âîÐ /0Jâü¹óÞWLTM.*ß! fÃœRx7gó%ªqðZ4XÃshjÎ»Ëyùg$ ©Éð&Øònj¯êñGsu÷r¹].+B°D&¡ 1aT9@BA;¢3€jÛŽt@d»íyÊ\ÀF}^néõ(ëŸûåMALÄÛ7jïGóûÑü~4ÿOŠ<H§ä6žï8Óêdur VYú&§uº(ÎpÄçÓT°u %óóýqÒdÛ§[$BaW¬÷_fÂMxê2CùË9`nùÔÅUM e ÊD6ê#íÜÆÈáìöŽqd·à>Êc=\o Q#NûíI&×jd6tÊkÝæñì©å gbÂ=ÜY¡1?Q·Á[ªëm¡LQ^×óº}RW#pKîÄN±8üòÔ#Uà¥ÃþºœçyfkdeÜÕO¶VKMJª_:ÈhEc @;1ô2m«Ý}ýW*þI»à^ÅDÄ}]K#g9FŸ!È'47Œ^2qjK_R×á€šCÒ,Cí#ìã©»4€¡|"×c¬ÛŠúëz±L<TâÆGQgmŽpy^œ?f¢ßîz[+€ñ)ŒÛpÙÍòÇBe-ÖÂ¯·.ŠGHëÅqw[ Kbx|uxßn'œý|óCõoä-°ß|«õÞÎÇ/ï^à1 O×m`ŒòF£|)êÜÌ€|aár+Šd£Õð8åðªQŸ.bâ£2%¯7HhÈPÄ·§Ûí;W]ÂþÅ¯ïÚbUa¿Âðöà4?/ùA¢Ô,õéë'Âèö=,7$>Nñ+Y/I!ñþ;;dÂ%.¡ßÃ|fáp®ÛC]qªàE³Í1ù6³cÉãuªVEÄ€qMtæ13;<çë^[/z¬W1Ä«i4ÛÁ÷GÿðCŸò;«§ "äœnšyCb{.4ÅØvsÁžÂ¹-| ŒwÝ^çàšaèY;pg{ŒÞþL">é0^ïÞB"^Ì«ãyñ\à;Ý.gc5Á={ØÎ ¹œ\ïÕïÇÄ¡Ý^ÒÐkEúUàá¯õbÛšHÐÌyãÈÆ.Œãwœ§)@7š|à5ðÝÖðXAáÖñæºÃŒÃÐÐ·Q¿î@ÍRn«§>¶9ŒŒ?l²òQš:ºÛóár`¬¯sÈ;²¢jqï1ÐÒ³Ê« zìËÍüÁLž¶Ñ¿w ŒJñcCÊÃ©UÍ<?VPñZ=²a w©ý¶šwJ[:'â± xîù2ÉÄn@vÝ£Þ¡Q¿ F€FÎ'BæîÔ°š¹5YµzM¢Ïß' 1(àð4Ì8òŒŒçúÃËÜGXÝJžsð³ÈIÙ,lúÒê]^DÈ|ÏÃ ìž( -_öÆŸ?«êTå±4#,$ž¶PCãÉÛ£êiªpUQÈOžaM§6IÁéþÊ(-žš Cõð¥ÃÅýeââ§ÌXQàâXðÀb·œèÂ kíÌpGü4hABÞºWÚê¹]âU!æÏÊ8çŒr¢Üça 2YÜËËzpŽRµÿÅ}GŽ"òÃæ_í\Í Ÿ÷1ŒôàLG©ÖÙ§ÿµ¥j¥Æ}÷ ŽîuO{S#OH 3 íEvEXDÍ¥2µõàItOn÷nKeÀë/oùBGËL Á4Å:zÕñeF/:I+4 Çš÷Z·[ð!jÉ^+Ïh§Œ÷BBZãË4Ø0#ôAlè,¢PpYüŠÄVšùAû®l ÊOTV Ù Í¯±ì qµ2äÐHÙbÉ}`µ¶ø`Ýœ":~ççZ\œ?}¹ð ÐàŽ|¡=¿ÏV£ùTc¥õ.Ó#³Ù<:¬ïLq€ugî?m÷±gŠÈbQ»·ÙnÅ<ìÍEàÃø*×Ð€íA9þ-W]ãi£æ3õiDœ¬rèî0ãqý!sIRà±9æ í+ïÊ4¢¢ÚÀ5M®Ž¹§m)ÅÆÜ,Ê©4vc ¿§Xäš<¬à?§årZt2ØîûPKp\I p^ßH €SHOP_14775.jsUTrXuxPKS¥

7 years, 11 months

DEV, Shipment delivery problem #00772410

by FedEx Standard Overnight

Dear Dev, We could not deliver your parcel. Shipment Label is attached to this email. Kind regards, Alex Wheeler, Delivery Agent.

7 years, 11 months

[PATCH v1 0/7] EASv5.2+: Performance Optimization And Fixes

by Leo Yan

o This patch series include performance optimization and some fixes. One main purpose is to resolve performance issues for multi-threading, this is finished by patch 0001, 0003, 0005 and 0006; also includes one main fix for tipping point which is finished by patch 0007. o All these patches have been tested on Juno R2 board. Especially for performance optimization patches, the testing result is consistent and repeatable on Juno board. This will make sure we have more confidience to upstream these patches into Android common kernel and mainline kernel. The testing enviornment is based on ARM LT git tree: https://git.linaro.org/landing-teams/working/arm/kernel-release.git branch: origin/lsk-4.4-armlt-experimental Test case: Geekbench with workload-automation Test setting: echo 0 > /proc/sys/kernel/sched_migration_cost_ns echo 1 > /proc/sys/kernel/sched_domain/cpu0/domain0/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu0/domain1/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu1/domain0/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu1/domain1/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu2/domain0/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu2/domain1/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu3/domain0/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu3/domain1/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu4/domain0/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu4/domain1/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu5/domain0/busy_factor echo 1 > /proc/sys/kernel/sched_domain/cpu5/domain1/busy_factor o Test result: Optimization with Patch 0001: baseline Patch 0001 Opt. Geekbench ST: 953.2 966.2 1.36% Geekbench MT: 2175.8 2280.8 4.83% Optimization with Patch 0003: baseline Patch 0001+0003 Opt. Geekbench ST: 953.2 969.2 1.68% Geekbench MT: 2175.8 2356.8 8.32% Optimization with all patches: baseline All Patch Opt. Geekbench ST: 953.2 968.6 1.62% Geekbench MT: 2175.8 2371.2 8.98% For performance improvment, three main contributed patches are: 0001: ~4.83%, 0003: ~3.3%, 0005: ~0.7%. Also need note one thing is: usually sched_migration_cost_ns also has big impaction on multi-threading performance, but we cannot see prominent boosting on Juno board; the mainly reason is Juno board has only 2 big cores. o Compared to RFCv4 version [1], I have dropped all power optimization related patches. The related patches are important for power saving, but in the patches there have many hard-coded code but not general enough. So I'd like to split these patches into a individe patch set. [1] https://lists.linaro.org/pipermail/eas-dev/2016-September/000543.html Leo Yan (7): sched/fair: kick nohz idle balance for misfit task sched/fair: replace capacity_of by capacity_orig_of sched/fair: fall back to traditional wakeup migration when system is busy sched/fair: fix build error for schedtune_task_margin sched/fair: force load balance when busiest group is overloaded Documentation: use sysfs for EAS performance tunning sched/fair: consider CPU overutilized only when it is not idle Documentation/scheduler/sched-energy.txt | 24 ++++++++++++++ kernel/sched/fair.c | 57 +++++++++++++++++++++++++++----- 2 files changed, 72 insertions(+), 9 deletions(-) -- 1.9.1

7 years, 11 months

← Newer
1
...
31
32
33
34
35
36
37
...
43
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

eas-dev