The v2 Rotary Interactivity Favor Scheduler

[kernelOfTruth]

sure:

http://pastebin.com/gaUv52Ue (valid 1 month)

[3766691]

sure:

http://pastebin.com/gaUv52Ue (valid 1 month)

CONFIG_NO_HZ=y

Could you turn it off and re-compile the kernel ?
Thanks.

As I say
The algorithm of RIFS-ES can be affected by variable clock interrupt.

[kernelOfTruth]

CONFIG_NO_HZ=y

Could you turn it off and re-compile the kernel ?
Thanks.

As I say
The algorithm of RIFS-ES can be affected by variable clock interrupt.

sure, will do

I read that there isn't that much of more power consumption:

http://www.phoronix.com/scan.php?pag...item=651&num=1


where others claim 10-20% more consumption:

http://ubuntuforums.org/archive/index.php/t-524694.html


now raw performance and efficiency counts (in terms of workflow) so I'll revert to tickless or more energy-friendly settings in 1-2 weeks ^^

[kernelOfTruth]

well, that massively helped

pulseaudio now continually seems to stay at 1% cpu load instead of pegging around 100-300%


it could have been partly an issue caused by configuration but I believe it's partly also due to tickless:

3c3
< # Linux/x86_64 3.4.2-geek Kernel Configuration
---
> # Linux/x86_64 3.4.2-geek_btrfs+_libata_RIFS-ES-v1-low-spec Kernel Configuration
113d112
< CONFIG_RCU_FAST_NO_HZ=y
319c318
< CONFIG_NO_HZ=y
---
> # CONFIG_NO_HZ is not set
326a326
> CONFIG_SCHED_OMIT_FRAME_POINTER=y
553d552
< CONFIG_CPU_IDLE_GOV_MENU=y
2113a2113
> # CONFIG_NTP_PPS is not set
3754,3755c3754
< CONFIG_UNWIND_INFO=y
< CONFIG_STACK_UNWIND=y
---
> # CONFIG_UNWIND_INFO is not set
3759c3758
< CONFIG_RCU_CPU_STALL_VERBOSE=y
---
> # CONFIG_RCU_CPU_STALL_VERBOSE is not set

it's still for 1-2 seconds stalling when it's heavily writing even though the dirty values are low as "1" - but that obviously might be caused by either luks/device-mapper or the filesystems and the other subsystems (VFS, writeback, etc.) involved


last kernel that - in my opinion - had really great writeback performance was 2.6.34, dunno


will stay on this kernel now ...


thanks !

[3766691]

sure, will do

I read that there isn't that much of more power consumption:

http://www.phoronix.com/scan.php?pag...item=651&num=1


where others claim 10-20% more consumption:

http://ubuntuforums.org/archive/index.php/t-524694.html


now raw performance and efficiency counts (in terms of workflow) so I'll revert to tickless or more energy-friendly settings in 1-2 weeks ^^

It seems that Tickless just help very little on power saving. On the other hand using tickless system can cause significantly high latency

[3766691]

well, that massively helped

pulseaudio now continually seems to stay at 1% cpu load instead of pegging around 100-300%


it could have been partly an issue caused by configuration but I believe it's partly also due to tickless:




it's still for 1-2 seconds stalling when it's heavily writing even though the dirty values are low as "1" - but that obviously might be caused by either luks/device-mapper or the filesystems and the other subsystems (VFS, writeback, etc.) involved


last kernel that - in my opinion - had really great writeback performance was 2.6.34, dunno

How about the subjective feeling between RIFS and RIFS-ES-Low-Spec ?

[kernelOfTruth]

How about the subjective feeling between RIFS and RIFS-ES-Low-Spec ?

like I wrote - I need that box for production - so I won't compile another RIFS with NOHZ right now (next week or after that at earliest)


otherwise it would be RIFS + tickless vs. RIFS-ES-low-spec + NOHZ

and that wouldn't be fair


in my opinion RIFS was more consistent but less fluid whereas RIFS-ES-low-spec was more smooth but at times also less smooth

this could be a whole different story with tickless disabled

[3766691]

like I wrote - I need that box for production - so I won't compile another RIFS with NOHZ right now (next week or after that at earliest)


otherwise it would be RIFS + tickless vs. RIFS-ES-low-spec + NOHZ

and that wouldn't be fair


in my opinion RIFS was more consistent but less fluid whereas RIFS-ES-low-spec was more smooth but at times also less smooth

this could be a whole different story with tickless disabled

NOHZ and tickless are the same things.

Actually I can't feel difference between RIFS and -ES but with benchmark data -ES would gain more improvement

[kernelOfTruth]

NOHZ and tickless are the same things.

Actually I can't feel difference between RIFS and -ES but with benchmark data -ES would gain more improvement

ah yes - I actually meant # NOHZ is not set


yeah, the differences are very subtle but under load RIFS-ES probably can really shine and show its strength



RIFS/-ES needs more testers and experiences to further improve and become even better


anyone ?



edit:

it's actually ridiculous how almost every app seemed to hog the cpu with NOHZ=y
(between 50-100% per app)

it might have been issues with the kernel over longer runtime - I'll see at the end of the time if it shows the same behavior or if it stays that calm with 0-1%

[3766691]

ah yes - I actually meant # NOHZ is not set


yeah, the differences are very subtle but under load RIFS-ES probably can really shine and show its strength



RIFS/-ES needs more testers and experiences to further improve and become even better

Ah, yes
Now the last things is we have to make it into modular.(Very last things) After this RIFS/-ES will support CGroups.
RIFS/-ES have beaten BFS but now we have to promote it more. If Gentoo developer can help me to promote I will say a big THANKS.

it might have been issues with the kernel over longer runtime - I'll see at the end of the time if it shows the same behavior or if it stays that calm with 0-1%

I seldom run my computer for long time but now I will try. Do you play LOL?