At a guess, because KernelNewbies.org is maintained by volunteers who may have had their own reasons for why they didn't have time to finish the 4.9 page?
4.9 was expected to be a long-term support release, so there was strong motivation to complete and merge anything that was almost ready. The maintainers knew this would happen and threatened to hold off on making a new longterm release until 4.10 or later if 4.9 ended up too full of half-baked code, but it seems to have mostly worked out as just a large release that is now officially the most recent longterm branch.
Interesting. I have a CPU with Intel Iris Pro graphics, which has 128MB of on-die eDRAM, which appears as L4 cache and which I assume can be used as both VRAM and cache.
I wonder if this is useful to me in terms of allocating/using it for the latter?
It is USB HID, but it seems there's a few quirks to adjust for. If you look through the linux HID code, that doesn't seem to be uncommon -- there's a lot of tweaking going on here. I'm sure the hardware was only tested against Microsoft's HID driver.
I'm not super knowledgeable of HID, but it seems like you can't query the device for HID Reports.
It opens the door for a lot of lowend providers to offer cheap GPU compute, since most are on kvm or OpenVZ. Excited for some $30/yr GPU assisted offers over on LowEndTalk :P
It'll also have a disruptive (sic) affect in VDI where you won't need high end nVidia or AMD GPUs to do VDI but can use decent intel ones and just carve them up. Then again you'll likely not get the performance that a dedicated high end GPU like the aforementioned ones provide with an integrated chip.
I would watch OVH for that. They already do a fair amount of cheap VPS. And, they already offer a server with 2 nice GPUs for $159/month: https://www.ovh.com/us/dedicated-servers/gpu/
So, they should be positioned to sell virtual GPU, since they already understand both demographics.
They just launched cloud desktops for about $78 USD a month, but those are Win10 boxes on VMWare with a dedicated AMD FirePro GPU, which is way overkill for most GPU accelerated needs.
I am a bit confused. Is this not GPU passthrough through VT-D anymore? Is this a virtual GPU that can render like the native GPU? Would I be able to use a GPU in Linux AND in a Windows VM at the same time?
> Is this not GPU passthrough through VT-D anymore?
No, this isn't just handing a PCI(e) device through to the guest.
> Is this a virtual GPU that can render like the native GPU?
Yes; it gives the guest a GPU that looks just like the host GPU, but virtualized. The host GPU does the actual rendering on behalf of the guest, securely, using guest memory.
> Would I be able to use a GPU in Linux AND in a Windows VM at the same time?
Yeah, I wonder how much of an improvement it will be on small, cheap, low I/O devices, any insight if you can prioritize some I/O over other I/O (like user interactive stuff vs Nautilus or cp duplicating a file)?
Use or compile a kernel with BFQ and that kind of stuff takes care of itself without manually having to prioritize I/O. I don't get why BFQ hasn't been mainlined yet, it has the most sane I/O behavior for desktop use and stops all the issues you can have on linux of the desktop slowing to a crawl or music stuttering because you're compressing a 40gb folder or copying files.
Here's a list of precompiled kernels that have been patched with BFQ (and often some more desktop-use tuning):
https://liquorix.net/#install for ubuntu and debian
If you're wary of installing things outside of official repositories or compiling your own kernel, then archlinux is the only distro with a kernel option that has BFQ.
> I don't get why BFQ hasn't been mainlined yet, it has the most sane I/O behavior for desktop use
You've answered yourself there: for desktop use. Desktop is a very low priority in the Linux world, as proven by the long history of ignoring desktop-friendly schedulers over and over.
BFQ hasn't been mainlined because it is written for the legacy block layer in the Linux kernel, which will be replaced entirely with the new block multiqueue implementation. It doesn't make much sense to replace CFQ or add a brand new scheduler only to rip it out in a few releases. Linux 4.11 will have support for I/O scheduling for blk-mq. BFQ is currently being ported to blk-mq; that work is the first big hurdle to getting it merged.
> If you're wary of installing things outside of official repositories or compiling your own kernel, then archlinux is the only distro with a kernel option that has BFQ.
From the page you linked:
> BFQ is the default I/O scheduler in Manjaro, Mageia, OpenMandriva, Sabayon, Arch Linux ARM (for Marvell Kirkwood) and ROSA ...
This kernel brings nearly full support (excluding Mali support) for Allwinner H3 based boards, and adds A64 support. I compiled 4.10-rc6 for my OrangePi a few days ago, and HDMI, audio, NAND flash, gigabit, wifi and everything else I tested worked well.
Finally got a super cheap version of a BeagleBone Black with the OrangePi Zero ($7), and with the OrangePi PC+ you get a board with a gig of ram and 8GB of fast eMMC for under $20.
Hopefully the H5 based boards and Arm64 in general will get better support, been having trouble getting NodeJS 6 or 7 running on aarch64 short of compiling it myself :(
Edit: Also FriendlyARM has a couple fun H3 based boards with the Nanopi Neo and a few others, might wanna look at those too!
DO NOT BUY THAT!!!! Get an OrangePi+ 2e, Xunlong released the OrangePi+ 2 and it has a USB Hub unlike other OrangePis (where you'd have 4x USB ports direct wired into the SOC, each can do 40MB/s) and a few other design compromises that make the OrangePi+ 2 a bad buy.
The Armbian people bitched at Xunlong for making such a terrible board and Xunlong replaced it with the OrangePi+ 2e, which is much better.
The OrangePi PC2 has directly wired USB ports for all four ports (3 normal USB, 1 microUSB OTG, same as Opi PC), but as far as everyone says, there is no 10 bit support for the H3 or H5. 8 bit works though :P
This is fantastic. I'd love to see more people in the "low-power" computer space. It's a nice constraint that isn't actually so tight that you can't do cool things. I'm pretty sure you could make use of these systems as a complete desktop which would be great: an entirely silent solid state system.
Yeah, if you look beyond the Raspberry Pi there are quite a few options, just things to keep an eye on are:
- MicroUSB for power - limits you to 2A, very bad
- Crap/slow eMMC - Look at random I/O as main method of judgment
- USB Hubs where they shouldn't be needed - OrangePi+ 2 made this mistake, get OrangePi+ 2e instead
- Poor board thermals - a good SBC will have a copper layer below the SOC to spread the heat across the PCB
- Non-mainline support - It might be great hardware, but its a dud without software
- Bad Power Supply - A phone charger is not a SBC power supply
- Slow MicroSD - Buy Samsung Evo 32GB cards, test immediately. Even with a good brand like these, 2 out of every 5 won't even do 10MB/s of write, or 2MB/s of random I/O, making them not a class 10 card. Exchange the bad ones, buy used if your on a budget.
Eh, that is only part of it, my comments were referring to genuine MicroSD cards, essentially Samsung's Evo cards are made using flash from their semiconductor fabs, and tend to have higher quality over Sandisk and basically all others since they buy random lots of flash off the open market.
That being said, Samsung isn't performance testing each microsd card, so you need to bench them ASAP when you get them to make sure your getting above 2MB/s in random I/O and around 20MB/s in write speed. If they fail that test (which if your buying more than one, you'll run across), just get it exchanged with the seller, no reason to hang onto a poorly performing card.
> Poor board thermals - a good SBC will have a copper layer below the SOC to spread the heat across the PCB
If that's the only thing wrong you can buy a few chip heat sinks and set it in a thermal epoxy to turn the entire thing into a thermally massive block. Even crap air flow should clean that up and then you don't need a case. You can also thermal glue it to a large bit of metal if you have a metal desk or something
That is both added cost and your still missing cooling the underside of the SOC. Most people will not take steps like that, so you end up with boards clocked at 900mhz instead of 1200mhz cause groups like Armbian don't want to burn up the SOC on users boards that don't have a heatsink.
Other bad moves are dumping 1.3v or 1.4v into the SOC and not allowing the user to adjust that voltage, cause then the board is just generating heat needlessly instead of running at 1.1v or so.
Nice to see Orange Pi PC being mentioned. It really is such a nice board. BTW, Armbian has experimental "mainline+patches" support for Orange Pi PC2, have you tried that?
Yeah, I have a few OrangePi PC2 boards that I built a kernel 4.10-rc6 image for, they seem to work fine (tho no working HDMI in my build) though I need to test them more. I'm planning to use them for a Ceph cluster, with four JMS567 USB 3.0 to SATA bridges ($2ea) on each SBC.
I figure with 160MB/s of I/O and gigabit ethernet, it'll be able to push files at a decent clip, dunno if it will max out my gig internet though.
A64 as in the chip that sits on the Pine64? I happen to have a Pine64 model PA642GB (aka PINE A64+ 2GB), which I bought after reading a comment on HN. After I received it I learned that the Linux support was actually terrible so I put it aside and haven't touched it since. Perhaps the situation is better now then?
Go grab Armbian for your Pine64, its the least worst thing you can put on it. The Pine64 itself is a terrible board, its limited to 1 USB port, the light on it doesn't tell the user whether the OS actually booted, and the microUSB connector allows people to use crap cables that don't provide enough power for it to boot, but provide enough power for the stupid LED to come on.
You could likely build a working image running kernel 4.10, Armbian has a build system for that or you can just use qemu-debootstrap.
They'll ship with a 4.x kernel eventually, but probably not until the specific release is aged :P
The main issue with Android devices running a mainline kernel is device drivers, these Qualcomm chips have a board support package which adds half baked support for their chip to some year or two old kernel, then a device vendor picks that chip and modifies android more, and then you end up with an ancient kernel on a brand new device. The only fix is for Qualcomm to mainline their device drivers.
> The only fix is for Qualcomm to mainline their device drivers.
And undermine their tried and true planned obsolescence strategy? Fat chance. Mainlining their drivers would disintermediate Qualcomm them from (obstructing) the Android upgrade process and could even lead to device upgrade cycles longer than 2 years (the horror!)
Linux will (thankfully) never do that because that would be an example of compromising technical quality for political reasons (mediating the problem that hardware makers are not publishing source).
Currently the ABI is very much the current code of each subsystem.
It's pretty much impossible to design an ABI that'll be future proof enough that it'd cover everything and yet would provide finetuned interfaces for each new gadget the kernel has to manage without significant loss of performance and/or functionality.
Two nice improvements: UID routing and ability to only keep conntrack tables for net namespaces that need them.
I'm working on a project right now using net namespaces. They provide very efficient ways of routing multitenant packets without cluttering up the init namespace.
I'm new to using a Linux-based OS as my primary - do you all generally stay on the latest and greatest? I setup 4.9.9 recently on my XPS DE. Is it risky at times to upgrade?
68 comments
[ 0.22 ms ] story [ 132 ms ] threadI thought they normally waited for all the stable releases to be completed before finishing the page.
From the original post:
> On the whole, 4.10 didn't end up as small as it initially looked. After the huge release that was 4.9
4.9 was "huge". I guess volunteers trying to cook up a quick summary may have given up on it :)
I wonder if this is useful to me in terms of allocating/using it for the latter?
I'm not super knowledgeable of HID, but it seems like you can't query the device for HID Reports.
So, they should be positioned to sell virtual GPU, since they already understand both demographics.
No, this isn't just handing a PCI(e) device through to the guest.
> Is this a virtual GPU that can render like the native GPU?
Yes; it gives the guest a GPU that looks just like the host GPU, but virtualized. The host GPU does the actual rendering on behalf of the guest, securely, using guest memory.
> Would I be able to use a GPU in Linux AND in a Windows VM at the same time?
Given appropriate Windows drivers, yes.
Here's the page on the BFQ I/O scheduler: http://algo.ing.unimo.it/people/paolo/disk_sched/
Here's a list of precompiled kernels that have been patched with BFQ (and often some more desktop-use tuning): https://liquorix.net/#install for ubuntu and debian
https://www.archlinux.org/packages/extra/x86_64/linux-zen/ for archlinux
http://download.opensuse.org/repositories/home:/tiwai:/bfq/ for opensuse, BFQ as a kernel module
If you're wary of installing things outside of official repositories or compiling your own kernel, then archlinux is the only distro with a kernel option that has BFQ.
You've answered yourself there: for desktop use. Desktop is a very low priority in the Linux world, as proven by the long history of ignoring desktop-friendly schedulers over and over.
BFQ hasn't been mainlined because it is written for the legacy block layer in the Linux kernel, which will be replaced entirely with the new block multiqueue implementation. It doesn't make much sense to replace CFQ or add a brand new scheduler only to rip it out in a few releases. Linux 4.11 will have support for I/O scheduling for blk-mq. BFQ is currently being ported to blk-mq; that work is the first big hurdle to getting it merged.
From the page you linked:
> BFQ is the default I/O scheduler in Manjaro, Mageia, OpenMandriva, Sabayon, Arch Linux ARM (for Marvell Kirkwood) and ROSA ...
Finally got a super cheap version of a BeagleBone Black with the OrangePi Zero ($7), and with the OrangePi PC+ you get a board with a gig of ram and 8GB of fast eMMC for under $20.
Hopefully the H5 based boards and Arm64 in general will get better support, been having trouble getting NodeJS 6 or 7 running on aarch64 short of compiling it myself :(
Edit: Also FriendlyARM has a couple fun H3 based boards with the Nanopi Neo and a few others, might wanna look at those too!
https://www.aliexpress.com/store/product/NEW-orange-pi-plus-...
Where could I find more info about these?
Update: Google to the rescue http://www.orangepi.org/orangepiplus2/
The Armbian people bitched at Xunlong for making such a terrible board and Xunlong replaced it with the OrangePi+ 2e, which is much better.
The power supply they offer is also pretty decent, so I'd nab it with that: https://www.aliexpress.com/item/Orange-Pi-Plus-2e-SET4-Pi-Pl...
https://forum.armbian.com/index.php/topic/1762-new-oranges-w...
- MicroUSB for power - limits you to 2A, very bad
- Crap/slow eMMC - Look at random I/O as main method of judgment
- USB Hubs where they shouldn't be needed - OrangePi+ 2 made this mistake, get OrangePi+ 2e instead
- Poor board thermals - a good SBC will have a copper layer below the SOC to spread the heat across the PCB
- Non-mainline support - It might be great hardware, but its a dud without software
- Bad Power Supply - A phone charger is not a SBC power supply
- Slow MicroSD - Buy Samsung Evo 32GB cards, test immediately. Even with a good brand like these, 2 out of every 5 won't even do 10MB/s of write, or 2MB/s of random I/O, making them not a class 10 card. Exchange the bad ones, buy used if your on a budget.
Aren't there a lot of counterfeits that's why?
That being said, Samsung isn't performance testing each microsd card, so you need to bench them ASAP when you get them to make sure your getting above 2MB/s in random I/O and around 20MB/s in write speed. If they fail that test (which if your buying more than one, you'll run across), just get it exchanged with the seller, no reason to hang onto a poorly performing card.
If that's the only thing wrong you can buy a few chip heat sinks and set it in a thermal epoxy to turn the entire thing into a thermally massive block. Even crap air flow should clean that up and then you don't need a case. You can also thermal glue it to a large bit of metal if you have a metal desk or something
Other bad moves are dumping 1.3v or 1.4v into the SOC and not allowing the user to adjust that voltage, cause then the board is just generating heat needlessly instead of running at 1.1v or so.
I figure with 160MB/s of I/O and gigabit ethernet, it'll be able to push files at a decent clip, dunno if it will max out my gig internet though.
A64 as in the chip that sits on the Pine64? I happen to have a Pine64 model PA642GB (aka PINE A64+ 2GB), which I bought after reading a comment on HN. After I received it I learned that the Linux support was actually terrible so I put it aside and haven't touched it since. Perhaps the situation is better now then?
You could likely build a working image running kernel 4.10, Armbian has a build system for that or you can just use qemu-debootstrap.
https://www.armbian.com/pine64/
http://www.theregister.co.uk/2016/10/05/linus_torvalds_admit...
Does this mean that one day, some beautiful day in the future, we can expect Android devices to ship with a modern kernel?
The main issue with Android devices running a mainline kernel is device drivers, these Qualcomm chips have a board support package which adds half baked support for their chip to some year or two old kernel, then a device vendor picks that chip and modifies android more, and then you end up with an ancient kernel on a brand new device. The only fix is for Qualcomm to mainline their device drivers.
And undermine their tried and true planned obsolescence strategy? Fat chance. Mainlining their drivers would disintermediate Qualcomm them from (obstructing) the Android upgrade process and could even lead to device upgrade cycles longer than 2 years (the horror!)
It's pretty much impossible to design an ABI that'll be future proof enough that it'd cover everything and yet would provide finetuned interfaces for each new gadget the kernel has to manage without significant loss of performance and/or functionality.
https://lists.debian.org/debian-devel-announce/2016/03/msg00...
Having related counters overflow at different times made it difficult to run calculations around network statistics.
I'm working on a project right now using net namespaces. They provide very efficient ways of routing multitenant packets without cluttering up the init namespace.