tag:blogger.com,1999:blog-6469704299235308349.post6715297295711088035..comments2024-03-28T15:50:13.644+11:00Comments on -ck hacking: Revisiting URW locks for BFSckhttp://www.blogger.com/profile/02904761195451530213noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6469704299235308349.post-7464755723168149672015-09-27T19:33:46.821+10:002015-09-27T19:33:46.821+10:00Kernel code can't run without any locking on S...Kernel code can't run without any locking on SMP processors. It will explode only microseconds into startup so it's impossible to do.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-7701246713030113442015-09-27T06:18:12.579+10:002015-09-27T06:18:12.579+10:00Heya,
Id be very interested in a benchmark on how...Heya,<br /><br />Id be very interested in a benchmark on how BFS performs with NO locking at all. <br /><br />I understand that it would be functionally incorrect, but how much overhead are you actually trying to remove from these spinlocks? What is the "absolute" improvement that could be had. zero lock measurements would be able to provide information on a total "gain" that could be had.MikeyBhttps://www.blogger.com/profile/07770752055681713027noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-67410541068630207492014-08-03T02:05:19.596+10:002014-08-03T02:05:19.596+10:00This patch to fix compilation issue in #2
bfs: Fi...This patch to fix compilation issue in #2<br /><br />bfs: Fix cpu_rq() compilation issue with CONFIG_SCHEDSTATS.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/3120cc663b1368dd312839b03c13e6d4966722c3Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-12481885074784039142014-08-02T02:03:27.547+10:002014-08-02T02:03:27.547+10:00@Manuel
Thanks for testing. It's caused by ena...@Manuel<br />Thanks for testing. It's caused by enabling sched stats, and I haven't tested it with this config. I will find some time to fix it this weekend. Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-36856189856882908802014-08-01T23:04:29.195+10:002014-08-01T23:04:29.195+10:00Patch 2 of this series (bfs: Make cpu_rq(cpu) a ma...Patch 2 of this series (bfs: Make cpu_rq(cpu) a macro instead of a function call) breaks kernel compilation for me:<br /><br /> LD init/built-in.o<br />kernel/built-in.o: In function `show_schedstat':<br />stats.c:(.text+0x2c7e5): undefined reference to `cpu_rq'<br />stats.c:(.text+0x2c862): undefined reference to `cpu_rq'<br />make: *** [vmlinux] Error 1<br /><br />Regards, ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-33165292197471436592014-08-01T19:32:43.006+10:002014-08-01T19:32:43.006+10:00Here comes my other branch of patches. 8 minor cha...Here comes my other branch of patches. 8 minor changes upon bfs 0.449. The previous post should be the right place to post these, but it looks like it is used to debug the issue with ath9k, so I post them here.<br /><br />@ck, please review the code when you are free.<br /><br />1. bfs: Remove get_cpu()/put_cpu() in try_to_wake_up()<br /><br />preempt_disable()/preempt_enable() also called in raw_spin_lock_irqsave()/raw_spin_unlock_irqrestore(), get_cpu()/put_cpu() are not necessary as mainline does.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/9583be334957efa456bac6f163f87c250b709807<br /><br />2. bfs: Make cpu_rq(cpu) a macro instead of a function call.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/e3c5ab20310f4cb5c5d36d2e8fcf99e5f918b7d5<br /><br />3. bfs: clean up wake_entry in task_struct<br /><br />This should be part of "[BFS] Remove runqueue wake_list", as wake_entry is just used for wake_list so it's no used in bfs.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/402ff574ab0661275d9ad0571c295c7712073d36<br /><br />4. bfs: Refactory idle!=prev and next task code in schedule()<br /><br />Just refactory the code and doesn't change the logic. Reduce a dupicated condition sentence and some not operations.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/35bad9b9b23fad50189bc2e4051f9f12544a44a7<br /><br />5. bfs: Remove unnecessary resched_suitable_idle() in schedule().<br /><br />When prev task is not the idle task and needs other cpu, the next<br />task will be returned from earliest_deadline_task() and will be<br />not the same task as prev task because the affinity.<br />resched_suitable_idle() will be called after prev != next check,<br />and resched_suitable_idle() call after needs_other_cpu() is not<br />necessary.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/74ad2a8ee96d6cd1382ce21e7c5e06070f07cda0<br /><br />6. bfs: comment out unused evaluated stack variables.<br /><br />Comment out evaluated cpu, rq and idle stack variables after context<br />switch, as they are not used in the rest of schedule(). Keep them in<br />source code so can be uncommented and use again.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/df01fbd98bc81ba4c607190fbbeabdcdde0f76b0<br /><br />7. bfs: Refactor rq dither calculation in schedule().<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/b68343be29c8bc9b22ae3115f59388176a50837f<br /><br />8. bfs: Refactory set_rq_task and inline reset_rq_task.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/856c8971381668f0742a841fdcf2140cf428ac25<br />Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-83403137025657953402014-07-31T19:04:30.285+10:002014-07-31T19:04:30.285+10:00Thanks for sharing your trying with URW locks and ...Thanks for sharing your trying with URW locks and continuing effect to make bfs sharper.<br />I am working on a multiple runqueue improvement. It hasn't finished and hard to tell the benefit vs the extra locking overhead yet.<br />Here I would like to ask about how to benchmark bfs besides throughput test? What statistics to look at? Many thanks.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.com