tag:blogger.com,1999:blog-6469704299235308349.post5624528203658372669..comments2024-02-09T16:24:46.087+11:00Comments on -ck hacking: Upgradeable rwlocks and BFSckhttp://www.blogger.com/profile/02904761195451530213noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-6469704299235308349.post-23606161709182519842012-06-28T17:40:04.960+10:002012-06-28T17:40:04.960+10:00(btw about that diagram: tlsf is the older incarna...(btw about that diagram: tlsf is the older incarnation of xvmalloc, kmalloc is slub)Kaelnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-82648784596149376312012-06-28T17:32:12.178+10:002012-06-28T17:32:12.178+10:00Hi all,
BFS and BFQ are now the default in all my ...Hi all,<br />BFS and BFQ are now the default in all my linux systems. However, I miss the old SLQB allocator so I was looking for a replacement for SLUB/SLAB.<br /><br />I've found xvmalloc, from compcache. It uses less memory than slub, however I've never used it:<br /><br />http://compcache.googlecode.com/svn/wiki/files/allocators_ideal_tlsf_kmalloc_compare.gif<br /><br />Have any of you tried it? What do you think?<br /><br />Thanks<br /><br />(note: crossposted at the bfq ml)Kaelnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-9429826531133096022012-06-27T03:02:04.851+10:002012-06-27T03:02:04.851+10:00@Ralph
I have make an RIFS-V3-Test. It is fully de...@Ralph<br />I have make an RIFS-V3-Test. It is fully designed for desktop and fit the 5511 option.<br /><br />However, the 1551 option cannot be implement by any scheduler.Or I can say, it is impossible to implement for both low latency or batch/throughput. They are two opposite things and we should prefer one of these two option.<br /><br />BFS is a 1515 scheduler.EEVDF(With BFS it is actually EDF) is actually the best real-time algorithm people have proven.<br /><br />Originally CFS(The one 2.6.23 kernel used) is good but Ingo expect to do something to fit all the workload type and CFS becomes not responsive.(On 2.6.31 kernel if we disabled the sleeper fairness CFS will even give very good responsive to users as BFS do, but after 2.6.31 the improved sleeper fairness feature has been hard-coded). <br />From CFS without sleeper fairness I can see that Unix System V scheduler is the best scheduler for desktop nomally.(CFS has the same approach as Unix Scheduler).Unluckily Linus prefer server users more and the pure Unix Scheduler is not adopted.<br /> ChenXhttps://www.blogger.com/profile/08096886089147792760noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-17021922475561851022012-06-26T20:20:43.130+10:002012-06-26T20:20:43.130+10:00Ralph,
Latency and throughput are heavily connect...Ralph,<br /><br />Latency and throughput are heavily connected. The value of one will affect the value of the other. They are on the same "value scale".<br /><br />Performance and Energy sound like implementation constraints, It either meets your requirements or it does not. There is no universal measurement.<br /><br />You have to define the requirements of the task you need a scheduler for; CFS is general, because it has to "fit all needs" as best it can, BFS is designed for desktop interactivity (with fairness) etc.<br /><br />Mike BrownMikeyBhttps://www.blogger.com/profile/07770752055681713027noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-90147149526507228202012-06-25T19:44:11.492+10:002012-06-25T19:44:11.492+10:00@Ralph Ulrich
RIFS is designed for mobile/desktop ...@Ralph Ulrich<br />RIFS is designed for mobile/desktop user.Xhttps://www.blogger.com/profile/08096886089147792760noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-14967380308496566892012-06-25T09:59:36.391+10:002012-06-25T09:59:36.391+10:00Chen, I know: NOHZ energy savings only ticks/gigaH...Chen, I know: NOHZ energy savings only ticks/gigaHerzOfCpu<br /><br />I wrote about four dimensions, because I want the developer of a scheduler (YOU) to emphasize on differentiation not univerality!<br /><br />What are the differences in regard of these four dimensions<br />(BFS - RIFS - RIFS/ES - CFS)<br />Chen you didn't answer this question yet, which I also asked at phoronix. You just say your scheduler performs (universal) better than CFS. This answer is a bug :)<br />Ralph UlrichAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-76360004425667580302012-06-25T02:18:10.821+10:002012-06-25T02:18:10.821+10:00"CFS mainline wants to satify all needs unive..."CFS mainline wants to satify all needs universally. I think a scientific informatical research project could easily show that in principle there cannot be a scheduler to fit the needs of all cases. " Yes it is. CFS wants to do that so but failed.<br /> <br />"1. energy consideration (think of no NOHZ of RIFS)"<br />Ah, a news on Phoronix has shown that there is only slightly improvement of energy costing with NOHZ.(Very little). On the other hand NOHZ will cause some problems on interactivity.Xhttps://www.blogger.com/profile/08096886089147792760noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-37583694437187692542012-06-25T01:55:30.320+10:002012-06-25T01:55:30.320+10:00Performance is a term meaning to comprise three di...Performance is a term meaning to comprise three dimensions:<br />1. energy consideration (think of no NOHZ of RIFS)<br />2. latency of response to users<br />3. throughput of data<br /><br />The last dimension most trivially to measure.<br />Regarding schedulers there is an additional dimension:<br />4. predictability (what realtime kernels want to provide)<br /><br />CFS mainline wants to satify all needs universally. I think a scientific informatical research project could easily show that in principle there cannot be a scheduler to fit the needs of all cases. <br /><br />Even if you think of a theoretical scheduler with adaptive strategies this artificial intelligence would cost much resources (energy and throughput).<br /><br />I would like to have a selection choice for users. Something indicated in four dimension by the user from 1-5 points:<br />5511 a mobile user would want<br />1155 an audiophile creater would select<br />1551 a developer compiling his latest source edits.<br /><br />Ralph UlrichAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-3280667263403014242012-06-24T20:00:22.492+10:002012-06-24T20:00:22.492+10:00Hi Con
I just want to clearify one thing. You said...Hi Con<br />I just want to clearify one thing. You said that RIFS/-ES optmises for big load, but actually I don't do that. Also there is *NO ANY INTERACTIVITY ESTIMATOR* in the design of RIFS/-ES. If you say that RIFS have sleep-based estimator I can claim that BFS also have sleep-based estimator(Actually both of them don't have this). <br /> ChenXhttps://www.blogger.com/profile/08096886089147792760noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-57786943321519106532012-06-23T06:40:29.493+10:002012-06-23T06:40:29.493+10:00> Thoughts?
i find a linear curve reassuring b...> Thoughts?<br /><br />i find a linear curve reassuring because it indicates a direct relationship between the quantities, meaning all influencers are known and there are no hidden surprises.Martinhttp://www.frogge.de/noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-9531737323301395642012-06-22T19:22:45.502+10:002012-06-22T19:22:45.502+10:00Well...
This RIFS code optimises for sleeping tas...Well...<br /><br />This RIFS code optimises for sleeping tasks under extreme loads. In other words, it adds unfairness favouring interactive tasks at loads of 64 or more. This is precisely the opposite direction of where the bfs code was heading, as it contains a sleep-based interactivity estimator (BFS has no interactivity estimator since they introduce unfairness and behave unpredictably) and it optimises for ridiculous loads that desktop users will never see.<br /><br />So while I'm happy to see people hacking on BFS, this code is pretty much orthogonal to the whole BFS approach.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-18737282377052191742012-06-13T15:33:10.213+10:002012-06-13T15:33:10.213+10:00Ok. But using the interface provided by mainline i...Ok. But using the interface provided by mainline is better because it can prevent producing bugs. Everyone hate bugs especially the bugs in the critical part of a OsXhttps://www.blogger.com/profile/08096886089147792760noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-40954785406111121542012-06-13T09:38:09.778+10:002012-06-13T09:38:09.778+10:00Thank you very much. It's clearly not a win, b...Thank you very much. It's clearly not a win, but then it's not a massive lose either. If it opens up other possibilities in the scheduler it may be worth pursuing, but for now it's not going to be part of "official" BFS just yet.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-37862777414820553292012-06-13T05:49:21.532+10:002012-06-13T05:49:21.532+10:00OK... did some testing using the my "make&quo...OK... did some testing using the my "make" benchmark. I think this endpoint is actually relevant in comparing the code with a reproducible and realworld relevant endpoint, albeit a non-interactivity one!<br /><br />1) It is a non-latency based measure.<br />2) Compilation benchmark using gcc to “make bzImage” for a preconfigured linux 3.4 build.<br />3) Runs benchmarks 28 times totally to get a decent number of observations for a statistical comparison. In all cases, the first run is omitted leaving an n=27.<br />4) Results are how many seconds it took to compile on a dual Intel E5620 (2x hyperhreaded quadcore CPUs on a single board) @ 2.40 GHz.<br />5) Make is run with 16 threads (8 physical cores and 8 HT cores).<br /><br />1st test: 3.4.2-bfs342 vs. 3.4.2-bfs3.4.2+urwlocks:<br />Result: The URWLocks patched kernel was on the borderline of achieving a statistically significantly difference. If I had powered the analysis with a larger number of replicates (say 63 or 72) I'll bet that it would be statistically significantly SLOWER than the unpatched bfs kernel. You can see from the Anova that the median time difference is 808 ms longer for the kernel running with the experimental patchset:<br /><br />http://s15.postimage.org/4uv2qx2bt/anova_1.jpg<br /><br />2nd test: 3.4.2-vanilla vs. 3.4.2-bfs3.4.2:<br />Result: The vanilla 3.4.2 kernel with the stock queuing system is statically significantly SLOWER than the corresponding bfs patched kernel; median time difference is 152 ms.<br /><br />http://s15.postimage.org/5rej32ux5/anova_2.jpg<br /><br />CK - Always glad to support your innovative ideas with regard to schedulers. Just ask and keep up the great work you do for the Linux community :)grayskyhttps://www.blogger.com/profile/16133632514577609343noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-22975737797829455002012-06-12T20:13:07.875+10:002012-06-12T20:13:07.875+10:00Hi Chen,
as a normal user I really appreciate you ...Hi Chen,<br />as a normal user I really appreciate you and H.Danton working on the issue. There is a need of differentiaton in the area of schedulers. Wouldn't it be great if there was a plugin infrastructure for this at mainline: I think this would be quiet simple just a few #ifdef SCHEDNAME in mainline code.<br /><br />Ralph UlrichAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-25652183820642001322012-06-12T06:30:26.169+10:002012-06-12T06:30:26.169+10:00I have a dual quad machine (8 physical cores + 8 H...I have a dual quad machine (8 physical cores + 8 HT cores) and will be glad to test this out... the most quantitative benchmark I have is my infamous "make" benchmark which I will run and post the results.<br /><br />Thanks for hacking CK, don't ever stop!grayskyhttps://www.blogger.com/profile/16133632514577609343noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-55159269257796399912012-06-12T03:05:57.398+10:002012-06-12T03:05:57.398+10:00Con, I think you should try to use the modular sch...Con, I think you should try to use the modular scheduler which mainline has.<br /><br />Doing this could make the code more stable. It doesn't means that BFS has to use per-cpu runqueue completely because the modular scheduler has also provide you a free space to do what you want.:-) In the other words, the patch can be smaller with this.(We just need to change a few lines of code in core.c , sched.h and rewrite the Makefile).<br /> ChenXhttps://www.blogger.com/profile/08096886089147792760noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-61051450630773927722012-06-12T01:05:41.728+10:002012-06-12T01:05:41.728+10:00I think it will be kinda difficult to find a BFS u...I think it will be kinda difficult to find a BFS user with so many cores to do proper tests. It's somewhat of an oxymoron :-)Anonymoushttps://www.blogger.com/profile/11469174621439712081noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-50123253512672719452012-06-12T01:00:18.625+10:002012-06-12T01:00:18.625+10:00Not particularly because of the delays in transact...Not particularly because of the delays in transactions and dependence on quiescent periods and so on.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-2350137675048478272012-06-12T00:57:51.545+10:002012-06-12T00:57:51.545+10:00What about RCU (Read-copy-update) — can it be used...What about RCU (Read-copy-update) — can it be used instead?Anonymousnoreply@blogger.com