Kernel: LWN Articles, Imagination, and Linutronix

-
Triggering huge-page collapse from user space [LWN.net]
When the kernel first gained support for huge pages, most of the work was left to user space. System administrators had to set aside memory in the special hugetlbfs filesystem for huge pages, and programs had to explicitly map memory from there. Over time, the transparent huge pages mechanism automated the task of using huge pages. That mechanism is not perfect, though, and some users feel that they have better knowledge of when huge-page use makes sense for a given process. Thus, huge pages are now coming full circle with this patch set from Zach O'Keefe returning huge pages to user-space control.
Huge pages, of course, are the result of larger page sizes implemented by the CPU; the specific page sizes available depend on the processor model and its page-table layout. An x86 processor will normally, for example, support a "base" page size of 4KB, and huge pages of 2MB and 1GB. Huge pages dispense with the bottom layer (or layers) of the page-table hierarchy, speeding the address-translation process slightly. The biggest performance advantage that comes from huge pages, though, results from the reduced pressure on the processor's scarce translation lookaside buffer (TLB) slots. One 2MB huge page takes one TLB slot; when that memory is accessed as base pages, instead, 512 slots are needed. For some types of applications the speedup can be significant, so there is value in using huge pages when possible.
That said, there are also costs associated with huge pages, starting with the fact that they are huge. Processes do not always need large, virtually contiguous memory ranges, so placing all process memory in huge pages would end up wasting a lot of memory. The transparent huge pages mechanism tries to find a balance by scanning process memory and finding the places where huge pages might make sense; when such a place is found, a range of base pages is "collapsed" into a single huge page without the owning process being aware that anything has changed.
There are costs to transparent huge pages too, though. The scanning itself takes CPU time, so there are limits to how much memory the khugepaged kernel thread is allowed to scan each second. The limit keeps the cost of khugepaged within reason, but also reduces the rate at which huge pages are used, causing processes that could benefit from them to run in a more inefficient mode for longer.
-
Random numbers and virtual-machine forks [LWN.net]
One of the key characteristics of a random-number generator (RNG) is its unpredictability; by definition, it should not be possible to know what the next number to be produced will be. System security depends on this unpredictability at many levels. An attacker who knows an RNG's future output may be able to eavesdrop on (or interfere with) network conversations, compromise cryptographic keys, and more. So it is a bit disconcerting to know that there is a common event that can cause RNG predictability: the forking or duplication of a virtual machine. Linux RNG maintainer Jason Donenfeld is working on a solution to this problem.
The kernel's RNG maintains an "entropy pool" from which random numbers are derived. As randomness from the environment is harvested, it is mixed into the pool, keeping the level of entropy up. Every running system has its own pool, naturally, with its own internal state. If two systems were to somehow end up with their entropy pools containing the same data, they would produce the same sequence of random numbers, for a while at least. That is something that should never happen.
But, as Donenfeld pointed out in a patch set first released in February, there is a way that two systems can end up with the same entropy-pool content. If a running virtual machine is somehow duplicated, the entropy pool will be duplicated with it. This can happen if a machine is checkpointed and restored, or if it forks for any reason. Once the restored or forked machine starts running, it will reproduce the sequence of random data created by the previous instance until the addition of new entropy perturbs the pool.
-
Toward a better list iterator for the kernel [LWN.net]
Linked lists are conceptually straightforward; they tend to be taught toward the beginning of entry-level data-structures classes. It might thus be surprising that the kernel community is concerned about its longstanding linked-list implementation and is not only looking for ways to solve some problems, but has been struggling to find that solution. It now appears that some improvements might be at hand: after more than 30 years, the kernel developers may have found a better way to safely iterate through a linked list.
-
Imagination open sources PowerVR Series 1 GPU drivers - CNX Software
Saying that Imagination Technologies is not exactly popular in the open-source community would be an understatement, but the company has just open-sourced the driver source for Power Series 1 GPUs namely Midas Arcade, PCX1, and PCX2.
If those names do not ring a bell, it might be because some of you may not have been born when PowerVR GPUs were first unveiled in 1995, and launched in products in 1996/1997. Developed jointly by VideoLogic and NEC, PowerVR was touted as the “future of high-quality 3D graphics for the next generation of interactive entertainment”, “whether you are developing 3D systems for console, PC, or arcade systems”. VideoLogic was renamed Imagination Technologies in 1999.
-
[Older] Is Intel about to make a significant Linux move?
Intel has quietly acquired a German software developer with the aim of bringing fresh life to a key, decades-old Linux kernel project.
In a blog post, vice president and general manager of system software engineering at Intel's Software and Advanced Technology Group, Mark Skarpness revealed that the company had acquired the German firm Linutronix which provides services for Linux-powered industrial systems and also specializes in real-time Linux applications.
While neither Intel nor Linutronix disclosed the financial terms of the deal, the acquisition is a sign that the chip giant wants to further commit to an incredibly important yet often overlooked Linux kernel project.
-

- Login or register to post comments
Printer-friendly version- 1722 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is released
After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release.
|
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future Tech
The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world.
Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility.
|
today's howtos
|








.svg_.png)
Content (where original) is available under CC-BY-SA, copyrighted by original author/s.

Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago