Language Selection

English French German Italian Portuguese Spanish

Intel’s 5G-oriented Atom P5900 features up to 24 10nm Tremont cores

Filed under
Linux

Like the C3000, the P5900 supports up to 128GB DDR4, now at up to 2933 MT/s. It similarly supports 16x PCIe 3.0, 16x SATA 3.0, 4x USB 3.0, and 4x USB 2.0 interfaces. However, the SATA links can now be reconfigured as up to 16x PCIe 2.0 or 16x USB 3.0, so you can now have up to 32x PCIe lanes. Other features include GPIO, 3x UARTs, and -40 to 85°C support.

We saw no mention of OS support, but we imagine that like the Atom C3000, the Atom P5900 is primarily designed to run Linux. The C3000 has appeared on a variety of Linux-powered networking appliances such as Advantech’s FWA-1012VC, as well as numerous COM Express Type 7 modules like Avnet/MSC’s MSC C7B-DV. Earlier this month, it showed up on a Versalogic Grizzly SBC.

Read more

More in Tux Machines

Audiocasts/Shows: Choose Linux, The Linux Link Tech Show, Bad Voltage

You Can Now Buy a PinePhone Preloaded with Ubuntu Touch

Ubuntu Touch, also known by the name UBports, is a community-maintained version of Ubuntu for phones and tablets based on Ubuntu 16.04 LTS. It is a direct continuation of the codebase Canonical cancelled a few years back. From today you (and anyone else interested) can preorder a PinePhone Community Edition with UBports direct from the Pine64 Store. Read more

Kernel: New LWN Articles and SELinux in Next Linux

  • Automatic buffer selection for io_uring

    The io_uring subsystem has, in the last year, redefined how asynchronous I/O is done on Linux systems. As this subsystem grows in both capability and users, though, it starts to run into limitations in the types of operations that can be expressed. That is driving a number of changes in how operations are programmed for io_uring. One example is the mechanisms considered for carrying a file descriptor between operations that was covered here in early March. Another has to do with how I/O buffers are chosen for operations. As io_uring developer Jens Axboe describes in this patch set, the usual mode for programs that handle large numbers of file descriptors is to use poll() to find out which descriptors are ready for I/O, then making separate calls to actually perform that I/O. One could use io_uring in this mode, but it defeats one of the purposes of the whole exercise: avoiding system calls whenever possible. The io_uring way of doing things is to just queue an asynchronous operation on every file descriptor, then react to the resulting events whenever one of those operations is executed. Working that way can indeed reduce system calls — all the way to zero if the request ring is kept full. But it also requires allocating a separate I/O buffer for each of those queued operations, even though many of them may not execute for an indefinite period of time. The poll() method, instead, allows an application to defer buffer allocation until a buffer is actually needed. Losing that flexibility can result in significantly higher memory use for applications that keep a large number of operations outstanding.

  • Working-set protection for anonymous pages

    A bit of background may be helpful for understanding how this patch set works; we'll start with a highly oversimplified picture, then add some details as we go. Virtual-memory systems allow applications to address far more memory than can actually fit into the physical memory installed in the system, so a significant part of any given process's address space is likely to exist only on secondary storage at any given time. Obviously, the pages that are in physical memory should be the ones that the process is going to use in the near future. The kernel cannot know for sure which pages will be useful, though, so it must fall back onto a set of heuristics that allow it to guess as well as it can. Some of those heuristics are reasonably straightforward. For example, if a process is observed to be working through a file sequentially, chances are pretty good that it will soon be wanting the pages of the file immediately after those it is accessing now. Another heuristic, found at the core of almost any virtual-memory implementation, is that pages that have been used recently are likely to be used in the future, while those that have languished unused for a while may not be worth keeping around. To implement that last approach, the kernel maintains a "least-recently used" (LRU) list; all user-space pages in physical memory are kept on that list. The kernel occasionally checks the pages on the LRU list and moves those that have been accessed recently to the head of the list. When more memory is needed, to bring in pages from secondary storage, for example, pages at the tail end of the list are reclaimed. In truth, the kernel maintains more than one LRU list. To begin with, the "LRU list" is actually two lists: the "active" and "inactive" lists. The active list functions mostly as described in the previous paragraph, except that, when pages fall off the tail of the list, they are put onto the inactive list instead. At that point, the protections on those pages are set to disallow all user-space access. Should some process access one of those pages, a "soft" page fault will result; the page will be made accessible again and returned to the active list. When memory is needed, pages will be reclaimed from the inactive list.

  • SELinux Seeing Performance Improvements With Linux 5.7

    A few months back when we last looked at the performance impact of having SELinux enabled there was a hit but not too bad for most workloads. But we'll need to take another look soon as with the Linux 5.7 kernel are some performance improvements and more for SELinux. The NSA-backed Security Enhanced Linux has seen a fair amount of work build up for the now-open Linux 5.7 kernel merge window.

Free and Open Source Software Leftovers

  • Selling Free and Open Source Software? With DRM?

    “What is everyones feelings on buying free/open source software? And if we are ok with that could we put DRM on the source code?" - Tom Ohhhhhh, boy. These are two intense questions. Short answer: Buying Free and Open Source Software = Great! Including DRM in, on, or anywhere near Free and Open Source Software (including on the source code itself) = The Opposite of Great!

  • Open Source Code - The Future of User Privacy

    Will we see more and more open source software in the future, or is this a passing trend that will die off eventually?

  • Helping FOSS conferences in the face of a pandemic

    The effects of the Coronavirus disease 2019 (COVID-19) pandemic are horrific and far-reaching; we really do not yet know just how bad it will get. One far less serious area that has been affected is conferences for and about free and open-source software (FOSS). On the grand scale, these problems are pretty low on the priority list. There are a fair number of non-profit organizations behind the gatherings, however, that have spent considerable sums setting up now-canceled events or depend on the conferences for a big chunk of their budget—or both. A new organization, FOSS Responders, has formed to try to help out.