<wwilly>
the dirtyness is still a secret for now, part of my thesis ... but I will test that without my stuff ...
<mszyprow>
wwilly: btw, for daily use, i would recommend disabling most of the debugging options enabled in exynos_defconfig (especially the locking related), kernel would run much faster then
<mszyprow>
wwilly: let me check it here
<wwilly>
mszyprow, ok for the debuging options. but for my comparison, if all comparator has this enabled, the comparison is fair and accepted I guess, or is it possible that I could touch corner case of bad performance comparing different in kernel scheduling strategy (schedutil with EAS, and dvfs governor ondemand/performance and thermal governor step_wise or user_space (for my own user_space research)?
<mszyprow>
wwilly: frankly, i would disable those options for measuring any performance related things
<mszyprow>
wwilly: they add a big overhead, so all the performance tests might be shifted somehow
<wwilly>
mszyprow, ok will do then
<mszyprow>
wwilly: or you might miss the differences because of the big delay introduced by the debugging things
<wwilly>
yes ok, like if EAS have more lock check than simply CFS, I might not compare the right timing I presume
<mszyprow>
exynos-defconfig i good for daily/regression tests only, for anything else, one has to tune it a bit
<wwilly>
do you have a recommendation of tuning? maybe do you have a production like defconfig for such board?
<mszyprow>
wwilly: also be careful with the debugging messages when doing performance tests - to make sure you don't measure the printk&friends performance :)
<mszyprow>
wwilly: sadly, nope, i don't have such
<mszyprow>
wwilly: a first show would be to simply disable the kernel debugging options
<mszyprow>
s/show/shot
<wwilly>
OK, yep obviously for the printing mécanisme :) my dmesg should be empty during testing, and it's currently not sometimes with this BUG and WARNING from time to time ...
<wwilly>
the thing is that, if I have this, there is maybe a more fondamental and deep issue somewhere in the kernel ...
<wwilly>
note that 5.4 serie doesn't have this BUG and WARNING, but I can't test EAS on this version as it's not in ... I haven't tested 5.8 though ...
<mszyprow>
wwilly: with a simply boot test i didn't observe that bug/warning yet
<mszyprow>
wwilly: do I need to do anything special in the userspace?
<wwilly>
uhm, launching some user binaries? I haven't tested simply with `stress`, I'm running some UTDSP (fft and other kernel) and NAS benchmark (kind of HUGE for this board, but it's still a workload)
LiquidAcid has joined #linux-exynos
<wwilly>
just install true last clean sources, with exynos_defconfig, simply boot it and run htop: https://pastebin.com/vNAJtWSN
mimi89999 has quit [Ping timeout: 265 seconds]
mimi89999 has joined #linux-exynos
mszyprow has quit [Ping timeout: 265 seconds]
mszyprow has joined #linux-exynos
<mszyprow>
wwilly: nothing like that happens here :/
<mszyprow>
wwilly: did you do anything special with the rootfs? i see debian 10 in the log. could you try a fresh install? if the is issue is still there then maybe you could share the image of sd card so I will check it here... no other ideas
genii has joined #linux-exynos
<wwilly>
the rootfs isn't on sd, but ssd
<wwilly>
u-boot on sdcard, it loads dtb and zImage then boot with rootfs on ssd; I'm /boot (not in use), /home, /var and /tmp on a separate fs
<wwilly>
the debian itself is fresh as this weekend
<mszyprow>
wwilly: okay, if i find some time i will check a fresh debian from usb drive then
<mszyprow>
wwilly: but i won't promise anything
<wwilly>
mszyprow, ok thanks
<wwilly>
you think it could be something in debian configuration somewhere?
<mszyprow>
wwilly: maybe it is usb related, i have everything on mmc
<wwilly>
ok
<mszyprow>
wwilly: i don't think so, but it might be related to the fact that rootfs is on usb
<wwilly>
I will test on a fresh sdcard tomorrow
<mszyprow>
wwilly: do you use usb 3.0 (dwc3/xhci) or 2.0 (ehci)?