I created my first Linux from scratch when I was a freshman in college in a third world country (not India). Fast forward few years later, I now write Linux kernel code for a living. Not sure what you did wrong, bud, to end up miserable like this.
Readit Newsafr0ck commented on The next two years of software engineering addyosmani.com/blog/next-... · Posted by u/napolux
Deleted Comment
afr0ck commented on Same-day upstream Linux support for Snapdragon 8 Elite Gen 5 qualcomm.com/developer/bl... · Posted by u/mfilion
Upstream would accept a patchset that exposed an independent Gunyah-specific UAPI (why not the same one as downstream — crosvm already supports that) instead of pretending to be KVM (it's not a "port", you can't port a hypervisor to a hypervisor).
KVM is available on current compute platforms (laptops) if you escape to EL2 via slbounce; and on Glymur (X2E) it will be available by default (yay!).
That's not how operating systems work. KVM is both an interface and a hypervisor. Just as we have different hypervisor implementations for amd, intel, arm and others all abstracted behind the same KVM interface, there is no reason the same can't be done for Gunyah. Userspace does not have to know anything about that. KVM already supports svm and vmx for amd and intel on x86. Why is something similar can't be done for Arm? Plus now there is pKVM.
I just don't understand this argument of a separate interface. The only reason you want to do that is to decouple from the KVM community, but that introduces a shit tone of duplicated effort and needless fragmentation to the virtualisation software ecosystem hindering your users from enjoying the existing upstream tools they already know about. In other terms, vendor locking and shitty downstream experience.
afr0ck commented on Same-day upstream Linux support for Snapdragon 8 Elite Gen 5 qualcomm.com/developer/bl... · Posted by u/mfilion
Does KVM hypervisor work? Previous Qualcomm CPUs have locked hypervisor mode behind Qualcomm proprietary blobs, and only allowed HyperV to use it - this was definitely the case for WOS laptops.
I worked at Linaro, who was contracting for Qualcomm. Qualcomm were pushing for some protected hypervisor called Gunyah (which had its own Linux interface and needed a new qemu port) that apparently no one liked. I tried to port it to KVM [1], but upstream folks (mostly Google) outright rejected the port. Otherwise KVM would have been available on QCOM boards. You can still try it. I have a Linux kernel and a Qemu port on my github [2,3]
[1] https://lore.kernel.org/kvm/20250424141341.841734-1-karim.ma...
[2] https://github.com/karim-manaouil/linux-next/tree/gunyah-kvm
afr0ck commented on Linux Career Opportunities in 2025: Skills in High Demand linuxcareers.com/resource... · Posted by u/dxs
afr0ck commented on Living my best Sun Microsystems ecosystem life in 2025 osnews.com/story/143570/l... · Posted by u/birdculture
> (200x) "Never bet against x86" -> (202x) "Never bet against ARM"
Citation needed. There is only 1 workstation maker with ARM: Apple.
There are Qualcomm laptops now I believe (at least that's what I heard when I was last working for them).
NXP also made some boxes (I own a bunch of them).
The server market is also growing with Ampere and Cavium (now Novell) which I have both.
afr0ck commented on AMD's EPYC 9355P: Inside a 32 Core Zen 5 Server Chip chipsandcheese.com/p/amds... · Posted by u/rbanffy
Those are extremely uniform latencies. Seems like on these CPUs most benefits from NUMA-aware thread-pools will be coming from reduced contention - mostly synchronizing small subsets of cores, rather than the actual memory affinity.
NUMA is only useful if you have multiple sockets, because then you have several I/O dies and you want your workload 1) to be closer to the I/O device and 2) avoid crossing the socket interconnect. Within the same socket, all CPUs shared the same I/O die, thus uniform latency.
afr0ck commented on GigaByte CXL memory expansion card with up to 512GB DRAM gigabyte.com/PC-Accessory... · Posted by u/tanelpoder
Yeah I saw the same. I've been keeping an eye on the CXL world for ~5 years and so far it's 99% announcements, unveilings and great predictions. But the only CXL cards a consumer/small business can buy are some experimental-ish 64GB/128GB cards that you can actually buy today. Haven't seen any of my larger clients use it either. Both Intel Optane and DSSD storage efforts got discontinued after years of fanfare, from technical point of view, I hope that the same doesn't happen to CXL.
I think Meta has already rolled out some CXL hardware for memory tiering. Marvell, Samsung, Xconn and many others have built various memory chips and switching hardware up to CXL 3.0. All recent Intel and AMD CPUs support CXL.
afr0ck commented on GigaByte CXL memory expansion card with up to 512GB DRAM gigabyte.com/PC-Accessory... · Posted by u/tanelpoder
What kind of motherboard, CPU, cables, switches, and end devices would I need to buy to have a CXL network?
CXL uses the PCIe physical layer, so you just need to buy hardware that understands the protocol, namely the CPU and the expansion boards. AMD Genoa (e.g. EPYC 9004) supports CXL 1.1 as well as Intel Saphire Rapids and all subsequent models do. For CXL memory expansion boards, you can get from Samsung or Marvell. I got a 128 GB model from Samsung with 25 GB/s read throughput.
It's not that deep. The futex was developed just to save you from issuing a special system call to ask the OS to put you on a wait queue.
The whole point is that implementing a mutex requires doing things that only the privileged OS kernel can do (e.g. efficiently blocking/unblocking processes). Therefore, for systems like Linux, it made sense to combine the features for a fast implementation.