Slashdot Mirror
Linux Kernel 4.10 Officially Released With Virtual GPU Support (softpedia.com)
"Linus Torvalds announced today the general availability of the Linux 4.10 kernel series, which add a great number of improvements, new security features, and support for the newest hardware components," writes Softpedia. prisoninmate quotes their report:
Linux kernel 4.10 has been in development for the past seven weeks, during which it received a total of seven Release Candidate snapshots that implemented all the changes that you'll soon be able to enjoy on your favorite Linux-based operating system... Prominent new features include virtual GPU (Graphics Processing Unit) support, new "perf c2c" tool that can be used for analysis of cacheline contention on NUMA systems, support for the L2/L3 caches of Intel processors (Intel Cache Allocation Technology), eBPF hooks for cgroups, hybrid block polling, and better writeback management. A new "perf sched timehist" feature has been added in Linux kernel 4.10 to provide detailed history of task scheduling, and there's experimental writeback cache and FAILFAST support for MD RAID5... Ubuntu 17.04 (Zesty Zapus) could be the first stable OS to ship with Linux 4.10.
It required 13,000 commits, plus over 1,200 merges, Linus wrote in the announcement, adding "On the whole, 4.10 didn't end up as small as it initially looked."
It required 13,000 commits, plus over 1,200 merges, Linus wrote in the announcement, adding "On the whole, 4.10 didn't end up as small as it initially looked."
Running 4.9 on 4 physical machines in my home. And also running 4.9 on over a dozen VMs in a datacenter without systemd.
There are a few distributions that don't push it down your throat. There are even a few others that offer (optional) alternative kernels and init systems.
Personally I use funtoo.
Take a look at www.without-systemd.org for more.
there is definitely support for nvidia
Vgpu seems very very cool. Now how can we turn this into something commercially viable?
-dk
Same with nvidia's own driver. Every time I've seen a machine where it looked like the nvidia driver was doing something wrong it's been a dead or dying fan on the card.
The nouveau driver is great for what it does, but if someone is going to be using google earth you need the one from nvidia. Both are rock solid for what they do IMHO (and the fans on video cards are frequently shit).
SystemD is in userspace. There are no dependencies for SystemD in the kernel.
Now I hate SystemD far more than most due to it causing actual failures for me in production, but spreading disinformation about it is dishonest.
My understanding is that it is more extensive: PCI(mostly 'e' these days) passthrough allows you to assign a physical device to a VM; but the device can't be shared: if a given piece of hardware is being passed through to one of the guests, none of the other guests or the host OS can use it.
This 'virtual GPU' stuff is supposed to make allocating GPU resources between VMs closer to how it is with CPU time or memory, where all the guests and the host can't exceed the capabilities of the machine they are running on; but they can all have access, with relatively modest overhead, to the same device.
I don't know if things work as pleasantly as desired yet; but in principle it should be a lot more convenient than full device passthrough. Especially in cases where you might be interested in the GPU for its computational capabilities, video transcoder, etc.
No, but it would help you run Windows CAD packages inside a Windows VM and get near native GPU performance both in the Windows VM and Linux host. vGPU lets you share a single compatible GPU across multiple VMs running on the same system. This way each VM can benefit from full hardware accelerated 3D rendering as well as access to OpenCL and/or CUDA even though only a single physical GPU is present in the system.
Wine wouldn't benefit because it already has direct access to the GPU as long as it's associated with the host system, it's issues are caused by imperfect compatibility between how Windows does something, and how WINE implemented it. For example, Wine translates Direct3D calls into OpenGL calls which can then be run natively in Linux, but if the translation isn't perfect, or a certain Direct3D call hasn't been implemented in WINE yet, then the program is going to behave differently than it should.