Fair enough - just warn that there could be fireworks ahead...
It would be one thing if the prempt patchset was in the kernel, but it's not as of yet -actively maintained, much like irqbalance - there a set of folks that are pretty adverse to mucking about with the scheduler out of tree...
goes back to how to manage forks inside github - if @pesa1234 is doing git right, it's trival to fork for your testing, and if good, can do the PR to merge back.
I think this is the safe approach here - but that's only my thoughts..
No need for separate thread, indeed i would be very much interested in knowing summery of this discussion in past, i seriously don't know what happened at my end but during a running system, plugged out my drive and plugged in and woov, it is detected right, see below
root@OpenWrt:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.87 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 1d5c:5011 Fresco Logic, Inc. USB2.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.87 xhci-hcd xHCI Host Controller
Bus 002 Device 002: ID 1d5c:5001 Fresco Logic, Inc. USB3.0 Hub
Bus 002 Device 003: ID 0bda:9210 Realtek RTL9210B
root@OpenWrt:~# lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/2p, 480M
|__ Port 002: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M/x2
|__ Port 002: Dev 003, If 0, Class=[unknown], Driver=uas, 5000M
root@OpenWrt:~#
Since than rebooted couple of times but I'm unable to produce issue, whatever it was, now disabled ksmbd and using block mount as well
Wifi performance is truly amazing, rock solid, played codm to test ping and it's as good as Ethernet connected
Tickless kernel is outside of perhaps what you're looking at - this is kernel plumbing stuff, and probably best for folks to see results rather than see what goes into the sausage...
What? I'm going to need you to expound on this one because I'm scratching my head here. The only thing I can assume you're referring to is the realtime patches that are outside of mainline (prior to kernel 6.12) and are needed to produce a realtime (read: not just tickless) kernel. That would also require enabling the PREEMPT_RT config attribute, which anyone who looked at my test patch would realize I did not enable.
Again, scratching my head here. It has to be tested somewhere (right??) and if it proves fruitful, it would be introduced via PR.
I know how forking and PRs work, thanks. My point earlier in this thread was that I have no intent in forking and producing my own test images. Obviously I have my own "fork" of Pesa's build with which I test against.
I have full confidence in saying right now that the patch I posted is "good" in that it has not broken any of my three MT6000s. It's not "testing" in that sense of the word. But what I am looking for is a few brave and interested individuals to join in testing with the kernel updates and run some benchmarks along with me to see if we can prove, or disprove, the efficacy of the patch on 1) network latency, 2) network jitter, and 3) network throughput.
I have the utmost confidence that if one knows how to take the patch I have put out there, build it into their own image, and flash to their device(s), they will have the technical prowess to come back to this forum and report back their findings. If one doesn't know how to apply the patch I put out there (or simply doesn't care to), then it's just not for that person at this time. Simple.
Maybe there is no measurable gain to be had. Maybe it causes a performance regression. That's the experiment, though, and we need to let the results speak for themselves.
I don't understand if you remove automount feature, but if you use block-mount I suggest to remove automount script located on: /etc/hotplug.d/10-mountdsk and 50-ksmbd
As far as I can tell, rcu_nocb_poll is a boot-time option only. So in order to include it in the boot string I added the CONFIG_CMDLINE and CONFIG_CMDLINE_FORCE=y options. In our MT6000 target, the CONFIG_CMDLINE is ignored unless CONFIG_CMDLINE_FORCE is enabled.
Because CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y is set, that implies rcu_nocbs=all and therefore there is no "housekeeping CPU" (per my understanding). Therefore rcu_nocb_poll allows RCU threads to be woken up with a timer.
A lot of this is subject to testing and tweaking, so there may very well be combinations of these kernel config options that lead to better or worse results. That's the fun in testing
PREMPT_RT was merged in with Kernel 6.12 (back in Sept '24).
I have no problem experiementing with it - just make sure that everything is tested - not just here and there...
There's times where I have to trust the systems engineering folks at Qualcomm and Mediatek - if preemption was beneficial, you can bet it would have been part of their respective SDK's
Found some weird bug in the latest release based on OpenWrt SNAPSHOT r29721-5111451803 - you cannot change network in Wifi-network settings, button Save doesn't react after changes
Not sure what you mean by “normalize them.” There are some really interesting things going on in that data. Some things were quite surprising. Don’t be too quick to dismiss them as noise.
I just created USR net to test this bug. I use VLAN18 for guest network and it is isolated on dedicated firewall device. I'm using Flint 2 as a dumb AP
My point earlier in this thread was that I have no intent in forking and producing my own test images. Obviously I have my own "fork" of Pesa's build with which I test against.
