Wonder if it's hard to make it SMP, if too many places use something like #ifdef CONFIG_ARCH_IS_UM to tell whether it is single CPU, it might be hard.

I've tried asking the Xilinx community, and got only a reply saying that there is a database in Yocto which limits the scalability.

1. Everytime a bb file is changed, it takes minutes to finish, for example, parsing recipes.

2. Building of a specific component takes minutes at the Yocto init things.

3. Invoking a Linux menuconfig takes minutes at the Yocto prologue and epilogue (e.g. resolving dependencies).

I see that Yocto manages the package in a way that provides good extensibility, modularization and maintainability. But it just way too slow.

I've heard that there is a database in Yocto which hinders the scalability, but why it seems that everyone using with Yocto doesn't mind waiting for minutes just for a minor config change?

Well, maybe I was wrong because I'm using Xilinx flavored (PetaLinux) Yocto.

How do you think?

Comments URL: https://news.ycombinator.com/item?id=42722659

Points: 2

# Comments: 5

AFAIK, although x86 and aarch32,64 domininate modern days computing world, it does seems there are still markets using PPC because the mainframe-oriented Power10 was released in late 2021 [1].

So, is there any story regarding why we seldom hear PPC nowadays but there's still PPC based servers releasing?

[1] https://www.wikiwand.com/en/articles/Power10

Comments URL: https://news.ycombinator.com/item?id=41589014

Points: 6

# Comments: 4

Also, if the overhead is negligible, maybe the author can try to merge this into mainline with the use of static key to make the incurred overhead switchable. In spite of the static key, the degree of the accompanied inteferences on cache and branch predictor might be an intriguing topic though.

https://twitter.com/Michell51304

So there's probably jitter in my headphones, or the app was not suppose to do music playback smoothly because that's not its main usage.

The sources of the stutters I can come up with are:

1. all available LITTLE cores are busy and at least a task wake up in the meantime. 2. the CPU scheduler doesn't schedule properly (from the user experience perspective). 3. music player doesn't advice itself as latency-sensitive app.

It's easy for modern smartphones to have ready_to_run_tasks (daemons) > available_cpus, and a CPU scheduler which ignores latency-sensitive apps can easily preempt the music player.

To sum up, user experience is probably the utmost thing that modern phones care, how can things like "stutters during music playing" happen? Can't we just defer those daemon tasks?

(maybe this is why my collegue got a MP3 player instead)

Comments URL: https://news.ycombinator.com/item?id=39971255

Points: 19

# Comments: 47

However, this got me wondering, is there exists any tool that can report the "numbers" (e.g., scheduling latency) regarding to the responsivenss? Maybe Google has such tool for testing regression for Android or Chrome OS, sadly, I didn't managed to find one.

Thanks!

[0] https://github.com/pop-os/system76-scheduler

Comments URL: https://news.ycombinator.com/item?id=30209366

Points: 100

# Comments: 44