Kernel: Moorestown, Nintendo 64, Corellium and Oracle

-
Linux Says Farewell To Intel's Smartphone Attempts With Clearing Out Moorestown / Medfield
Not only are some old ARM platforms and some obsolete, obscure CPU architectures on the chopping block for some spring cleaning in the Linux kernel, but the Intel Moorestown and Medfield "Mobile Internet Device" platforms are being phased out from the Linux kernel this spring as well.
Moorestown was Intel's early Atom platform geared for handheld mobile Internet devices and smartphones.
-
With Linux 5.12 Set To Boot On The Nintendo 64, The N64 Controller Driver Is Now Queued - Phoronix
A few days ago we wrote about Linux 5.12 to see support for the Nintendo 64 more than two decades after that MIPS-based video game console first shipped. While the practicality of Linux on the Nintendo 64 is particularly limited given only 4~8MB of RAM and the MIPS64 NEC VR4300 clocked under 100MHz, it's going upstream and now the N64 controller driver is also queued for this next kernel cycle.
The code talked about a few days ago was getting Linux to boot on the Nintendo 64. With those 200+ lines of code in the MIPS architecture space is enough to get Linux booting on the Nintendo 64 when using a Flashcart device to be able to load the arbitrary code onto the game console.
-
Corellium to offer cloud-based iOS virtualisation to individual accounts
The company, which only recently ported Ubuntu Linux to work on Apple Silicon Macs, has announced on their blog that they will now offer their virtualisation tools for iOS to individual accounts on their CORSEC platform. Previously, only enterprise accounts could access the service, while individuals could only access virtual Android devices.
-
Getting started with SystemTap on Oracle Linux
There are a wealth of tools available for tracing and debugging the Linux kernel on a live system. These include Kprobes, Ftrace, trace-cmd, Dtrace, eBPF, SystemTap, crash, gdb, etc. Among these tools, few allow the user to develop and re-use scripts that can filter events and collect data more than just function arguments and returned values. Dtrace, eBPF and SystemTap are the ones among these tools that do.
-
Anticipating Your Memory Needs
The Linux kernel organizes physical memory in units of pages of a certain size called base pages. For example, the default base page size when running on Intel processors is 4KB. These pages are allocated to user and kernel tasks as they need memory. When processing large amounts of data from slower disk devices, the Linux kernel uses a page cache to cache contents, like disk blocks, to speed up access to frequently accessed data. See this article for more details on how various caches are used by the Linux kernel. This has the positive effect of improving overall system performance but the memory for page cache must come from the same memory pool that is used by rest of the system. The kernel allocates all the memory not currently in use to the page cache. As the kernel needs to allocate more memory for other tasks, it can reclaim pages from the page cache since the contents in the page cache can be restored from disk blocks when the need arises. Reclamation happens as the kernel starts to run low on free memory pages. Individual memory pages are the base pages. As pages are reclaimed, any contiguous base pages are grouped together (compaction) to form higher order pages. Higher order pages are groups of 2^n physically contiguous pages where n is the page order. Higher order pages can then be used to satisfy higher order page allocation requests, for example if an allocation request is for 8 pages, that allocation will be made from order 3 page group.
The kernel recovers physical memory in the event of a shortage by page reclamation and/or compaction. Both methods are implemented in a similar fashion. As the amount of free memory falls below the low threshold (watermark), memory pages are reclaimed asynchronously via kswapd or compacted via kcompactd. If the free memory continues to fall below a minimum watermark, any allocation request is forced to perform reclamation/compaction synchronously before it can be fulfilled. The latter synchronous method is referred to as the "direct" path and is considerably slower owing to being stalled waiting for memory to be reclaimed. The corresponding stall in the caller results in a non-deterministic increased latency for the operation it is performing and is typically perceived as an impact on performance.
-
- Login or register to post comments
Printer-friendly version
- 2538 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Red Hat/Fedora Leftovers
| The Innovation Lab: A Space for Creative Learning
The reason why we use System76 to power all the computers in the space is because I’m a big supporter of Linux in general, and System76 has been really consistent and helpful. I think the openness of System76 definitely gives the students the ability to experiment and the freedom to break stuff in a creative environment, without being too constrained by proprietary software.
|
GNOME Foundation and Linux Foundation Leftovers
| Istio 1.7.8 Released
This release contains bug fixes to improve robustness. This release note describes what’s different between Istio 1.7.7 and Istio 1.7.8
|
Linux on Apple M1 Project Reveals New Details About M1 System
Linux on Apple M1 Project Reveals New Details About M1 System Architecture
New Patches Posted For Bringing Up The Apple M1 SoC On Linux
New Patches Posted For Bringing Up The Apple M1 SoC On Linux