Language Selection

English French German Italian Portuguese Spanish

Linux Kernel, Linux Foundation and Graphics

Submitted by Roy Schestowitz on Thursday 12th of July 2018 04:14:50 AM Filed under
Graphics/Benchmarks
Linux
  • The final step for huge-page swapping

    For many years, Linux system administrators have gone out of their way to avoid swapping. The advent of nonvolatile memory is changing the equation, though, and swapping is starting to look interesting again — if it can perform well enough. That is not the case in current kernels, but a longstanding project to allow the swapping of transparent huge pages promises to improve that situation considerably. That work is reaching its final stage and might just enter the mainline soon.

    The use of huge pages can improve the performance of the system significantly, so the kernel works hard to make them available. The transparent huge pages mechanism collects application data into huge pages behind the scenes, and the memory-management subsystem as a whole works hard to ensure that appropriately sized pages are available. When it comes time to swap out a process's pages, though, all of that work is discarded, and a huge page is split back into hundreds of normal pages to be written out. When swapping was slow and generally avoided, that didn't matter much, but it is a bigger problem if one wants to swap to a fast device and maintain performance.

  • Revisiting the MAP_SHARED_VALIDATE hack

    One of the the most commonly repeated mistakes in system-call design is a failure to check for unknown flags wherever flags are accepted. If there is ever a point where callers can get away with setting unknown flags, then adding new flags becomes a hazardous act. In the case of mmap(), though, developers found a clever way around this problem. A recent discussion has briefly called that approach into question, though, and raised the issue of what constitutes a kernel regression. No changes are forthcoming as a result, but the discussion does provide an opportunity to look at both the specific hack and how the kernel community decides whether a change is a regression or not.

    Back in 2017, several developers were trying to figure out a way to safely allow direct user-space access to files stored on nonvolatile memory devices. The hardware allows this memory to be addressed directly by the processor, but any changes could go astray if the filesystem were to move blocks around at the same time. The solution that arose was a new mmap() flag called MAP_SYNC. When a file is mapped with this flag set (and the file is stored on a nonvolatile memory device), the kernel will take extra care to ensure that access to the mapping and filesystem-level changes will not conflict with each other. As far as applications are concerned, using this flag solves the problem.

  • Take Our Survey on Open Source Programs

    Please take eight minutes to complete this survey. The results will be shared publicly on The New Stack, and The Linux Foundation’s GitHub page.

  • Mesa 18.1.4 release candidate

    Mesa 18.1.4 is planned for release this Friday, July 13th, at or around 10 AM PDT.

  • Mesa 18.1.4 Being Prepared With Intel Fixes & A Couple For Radeon

    Another routine Mesa 18.1. point release is being prepared while waiting for the August debut of the Mesa 18.2 feature update.

    Dylan Baker, the Mesa 18.1 release manager and his first stab at the task, has announced the Mesa 18.1.4 release candidate today. In its current form, Mesa 18.1.4 is comprised of just over two dozen patches.

  • Pre-AMDGPU xf86-video-ati X.Org Driver Sees A Round Of Improvements

    It's rare in recent years to have anything to report on xf86-video-ati, the X.Org driver for the display/2D experience for pre-GCN Radeon graphics cards. But this week has been a large batch of fixes and improvements for those using this DDX driver with pre-HD7000 series hardware.

    Longtime Radeon Linux driver developer Michel Dänzer has landed a number of commits already this week of various fixes/cleanups, some of which were inspired by the xf86-video-amdgpu DDX driver that is used for current-generation hardware with the AMDGPU kernel driver (unless using xf86-video-modesetting...).

»

More in Tux Machines

Openwashing: Zenko (Dual), Kong (Mere API) and Blackboard (Proprietary and Malicious)

Games: Descenders, War Thunder’s “The Valkyries”

Kernel: Virtme, 2018 Linux Audio Miniconference and Linux Foundation Articles

  • Virtme: The kernel developers' best friend
    When working on the Linux Kernel, testing via QEMU is pretty common. Many virtual drivers have been recently merged, useful either to test the kernel core code, or your application. These virtual drivers make QEMU even more attractive.
  • 2018 Linux Audio Miniconference
    As in previous years we’re trying to organize an audio miniconference so we can get together and talk through issues, especially design decisons, face to face. This year’s event will be held on Sunday October 21st in Edinburgh, the day before ELC Europe starts there.
  • How Writing Can Expand Your Skills and Grow Your Career [Ed: Linux Foundation article]
    At the recent Open Source Summit in Vancouver, I participated in a panel discussion called How Writing can Change Your Career for the Better (Even if You don't Identify as a Writer. The panel was moderated by Rikki Endsley, Community Manager and Editor for Opensource.com, and it included VM (Vicky) Brasseur, Open Source Strategy Consultant; Alex Williams, Founder, Editor in Chief, The New Stack; and Dawn Foster, Consultant, The Scale Factory.
  • At the Crossroads of Open Source and Open Standards [Ed: Another Linux Foundation article]
    A new crop of high-value open source software projects stands ready to make a big impact in enterprise production, but structural issues like governance, IPR, and long-term maintenance plague OSS communities at every turn. Meanwhile, facing significant pressures from open source software and the industry groups that support them, standards development organizations are fighting harder than ever to retain members and publish innovative standards. What can these two vastly different philosophies learn from each other, and can they do it in time to ensure they remain relevant for the next 10 years?

Red Hat: PodCTL, Security Embargos at Red Hat and Energy Sector

  • [Podcast] PodCTL #50 – Listener Mailbag Questions
    As the community around PodCTL has grown (~8000 weekly listeners) we’ve constantly asked them to give us feedback on topics to discuss and areas where they want to learn. This week we discussed and answered a number of questions about big data and analytics, application deployments, routing security, and storage deployment models.
  • Security Embargos at Red Hat
    The software security industry uses the term Embargo to describe the period of time that a security flaw is known privately, prior to a deadline, after which time the details become known to the public. There are no concrete rules for handling embargoed security flaws, but Red Hat uses some industry standard guidelines on how we handle them. When an issue is under embargo, Red Hat cannot share information about that issue prior to it becoming public after an agreed upon deadline. It is likely that any software project will have to deal with an embargoed security flaw at some point, and this is often the case for Red Hat.
  • Transforming oil & gas: Exploration and production will reap the rewards
    Through advanced technologies based on open standards, Red Hat deliver solutions that can support oil and gas companies as they modernize their IT infrastructures and build a framework to meet market and technology challenges. Taking advantage of modern, open architectures can help oil and gas providers attract new customers and provide entry into markets where these kinds of services were technologically impossible a decade ago.

More on Tux Machines: About ● Gallery ● Forum ● Blogs ● Search ● News ● RSS Feed

Part of Bytes Media ● Sister sites below.

TechBytes Techrights button

Powered by Drupal, an open source content management system

Content available under CC-BY-SA CC

© by original authors

Powered by CentOS 6.5 (GNU/Linux), Varnish, and Drupal 6