Tiny Core 14.0 Alpha 1 Testing

[Rich]

Hi GNUser
These are the extensions that were corrected:

x86
cpufreqd.tcz
fakeroot.tcz
gfortran.tcz
gnome-themes-standard.tcz
openldap.tcz

x86_64
gfortran.tcz
gnumeric.tcz
libfm-dev.tcz
libfm-extra-dev.tcz
openldap.tcz

[GNUser]

Hi, Rich. Yes, I can confirm that loading gnumeric.tcz now causes no errors when loading downstream extensions.

Hi, curaga. I can confirm that v5 of the kernel patch (available at https://patchwork.kernel.org/project/linux-wireless/patch/20221230200747.19040-1-nbd@nbd.name/ and also attached) works as advertised.

I applied the patch to the TCL14 kernel source. Then I compiled the mac80211.ko module and repackaged wireless-6.1.2-tinycore64.tcz with it. Router is working perfectly now, creating the usual blazing-fast 802.11ac AP, crash-free.

[curaga]

It takes some time to do a full kernel build, so generally we don't do a respin unless there's some serious bug. IMHO this is not big enough, and you're likely the only one using TC as a router with that wifi stick - but good to hear you have it working with a custom extension.

BTW it looks like Felix posted some mt76 fixes a week ago, if you hit other crashes they may be needed.

[GNUser]

Hi, curaga. Thanks for the tip regarding the mt76 fixes.

I just want to point out that only the one module in wireless-KERNEL (mac80211.gz) had to be swapped because that's all that the patch changes. I'm still using the kernel image (vmlinuz64) and modules initrd (modules64.gz) that you guys released as alpha version. I mention this here in the off chance that it is helpful to anyone.

[gadget42]

thanks for that clarification

[GNUser]

Hi, curaga. Would you like me to submit wireless-6.1.2-tinycore64.tcz with no changes except patched mac80211.gz (I've tested it extensively and it's working perfectly)? If so, I'd be happy to. If not--e.g., because you want the kernel and all modules to come from same full kernel build--I totally understand.

Juanito, I submitted a bunch of refreshed networking-related packages for TCL14 64bit.

I hope TCL14 is the best release ever

[curaga]

I do want to keep the original modules from one build, but you're welcome to submit it under another name. Then the info file can cover when it's useful and to rename it, etc.

[GNUser]

Hi, curaga. I submitted it under another name, with an info file as you suggested. Thanks.

[mocore]

... how to run shell scripts and commands from each core.
What commands have the capabilities to do that.

...

numactl or taskset command's

[nick65go]

Maybe this is silly question ??
Is it possible to make tc boot faster ??
...
Just having only one command in mind that spans the commands in separate cores.

IMHO, to boot TC faster, I used to combine tcz for onboot. ex: all tcz+deps for Xorg-server (100+ tcz) into one Xorg-full.tcz; same for gtk3-full.tcz, ffmpeg4-full.tcz etc. I gain 10+ seconds in boot speed. What target gain (in seconds) do you aim for?

Another idea could be to improve the awk "golden engine" of "tce-load" for loading tcz. Because this engine first builds a full list of dependencies (for all tcz to be loaded) and then it loads / unsquashes them sequentially. So test for cpu-cores and then the loading list (of independent tcz) can be split-ed for total CPU cores.

PS:TC aims for CPU 486 compatibility, so it was no interest for multi-core. But in year 2023, and 64 bits era, then SMP (symmetric multi-processing) rises its head.

[patrikg]

I am not aiming for booting faster, just saying that we can use our multi-core CPU more efficient.
And use the parallell, could maybe be some good solution, but what i think you need to make some kind of dep tree, to see whats the system need to extract first, and like you sayed you could combined the extensions together, just extract them all first into some tmp directory and then compress them all into one piece.

[nick65go]

@patrikg: I am glad that you agree with the idea to combine tcz into one big for huge tcz+deps (like Xorg server) 

Regarding multi-core CPU: It is a waste of (expensive) electricity to have 100 cores and NOT use all together for 1 second, instead of one core for 100 seconds (the 99 cores just sleeping). But it is a say, like "double of nothing is nothing!". 
Because I am not a programmer/developer, for me the Pareto principle apply, 80% efficiency with 20% work. So spending (2-3 hours ) time to "improve" tce-load, just to recover them in 2-3 years, is not worth for my time. ex: 365 days/year x 3 years / (10 sec / 60 sec/min / 60 min /hour => 3.04 hours.

PS: the "deep" tree can be seen from TC appls, or from /tmp/tcload/extensions.

[CNK]

Regarding multi-core CPU: It is a waste of (expensive) electricity to have 100 cores and NOT use all together for 1 second, instead of one core for 100 seconds (the 99 cores just sleeping). But it is a say, like "double of nothing is nothing!". 
Because I am not a programmer/developer, for me the Pareto principle apply, 80% efficiency with 20% work. So spending (2-3 hours ) time to "improve" tce-load, just to recover them in 2-3 years, is not worth for my time. ex: 365 days/year x 3 years / (10 sec / 60 sec/min / 60 min /hour => 3.04 hours.

The kernel does most of the work, the "mount" and "cp -ais" commands called from tce-load largely just tell the Linux kernel what to do. The kernel already multi-threads itself. You can list all the kernel threads currently running with:

Code: [Select]

ps | grep '\['

Currently I've got 86 kernel threads, so if I had 100 CPU cores I might have some to spare, but as it is I've only got four. If I run top and press "1" to see all the CPU cores while loading an extension with many dependencies at the same time, all four cores show an increased "sys" usage, so the kernel must be having some success at splitting the mount and symlink tasks over all four cores.

[nick65go]

@CNK: I have also just 4 cores ( maybe 2 cores , 4 threads?) on my AMD APU,  so will be no big deal if (or not) tce-load will load TCZs in parallel.  But I saw a big difference using a manually made Xorg-full.tcz , because CPU was not switching to each thread/ tc-loop. Or maybe reading each tcz from rotational/slow HDD when faster cores are already sleeping waiting for I/O data not in RAM / cache.

It was all theoretically. I understand that a 4-core CPU will split the workload in maxim 4 threads for the same command ( to load one tcz). The possible improvement discussed was about loading many (100) tcz in parallel. Be cause the B-two tcz have to wait (is a sequential list of dependency) until A-one.tcz finish (loaded by 4 threads in parallel), even if (in the mean time) 3 cores finish A-one.tcz but 4-th core still process the last thread of A-one.tcz. [so I think]. So was about few n-1 core sleeping because at least one core still process the initial command.

[nick65go]

Maybe another option, for faster 100 tcz loading, could be to have a tce-load switch /parameter on boot, to on-demand bypass loading 100 md5 files (tcz checksum) from a slow HDD, plus then implicit bypassing 100 calculation + comparisons of those md5. Or maybe ordering index/files in squash tcz, because Xorg will not show until all .so are loaded from many tcz.

PS: I wonder how many programs (as % from total) still run under Xvesa /Xfbdev in today tc14. Because most of them ask for gtk3, which in turn ask for Xlibs -> Xorg. Any proper (modern) browser  asks for Xorg.