SFC Considers Combining ZFS With Linux A GPL Violation

[chithanh]

drSeehas
As I said, the hardware that I bought around the time Windows 2000 was released still works with today's Linux distributions, with one exception (the PowerVR Kyro 2 which had only proprietary drivers).

All the driver API stability didn't help Windows, every peripheral from back then is now a paperweight from the Windows perspective.

[duby229]

"On what distros I see this mess"? Well, it is not that _I_ see that. There are lot of other people seeing this mess too. Even Linux kernel developers:

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Stable-API-ABI

Artem Tahskinov writes:
"It's not a secret that there are two basic ways of running a Linux distribution on your hardware. Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you are prone to regressions. This problem can be solved by decoupling drivers from the kernel and supplying them separately so that you could enjoy stable kernel version X with brand new drivers like it's done in most other proprietary OS'es. I've been thinking of asking Linus about this decoupling for years already but I'm hesitant 'cause I'm 99.99999% sure he will downright reject this proposal."

Maybe you should inform he that he is doing it wrong, and he is an idiot?

That guy definitely is an idiot. No doubt about that at all. Did you read his retarded rant?

[bridgman]

So we have 6/3/6 years driver API stability. And now compare to Linux.

Seems pretty similar to Linux, as long as you are running an enterprise distro (where the existing kernel is updated rather than moving to new kernel).

[drSeehas]

Seems pretty similar to Linux, as long as you are running an enterprise distro ...

Which are RHEL/CentOS, SLES/SLED, Debian stable and Ubuntu LTS. I forgot one?
4 out of 250+ distributions.

BTW: Is Carrizo-L Sea Islands or Volcanic Islands? IOMMUv1 or IOMMUv2?

[bridgman]

Yep, those are the main ones... 4/250 distros might be true but they also probably represent 70 or 80 percent of business/commercial installations.

Carrizo-L is CI, Stoney Ridge is VI. Both support IOMMUv2, although IIRC Carrizo-L only generates 40-bit GPU addresses so it's not a good HSA target. IIRC Stoney generates 48-bit addresses so could potentially run full HSA stack I guess (never thought about it before).

BTW in another thread (the Radeon Open Compute one) I was talking about the difference between HSA/IOMMUv2 paths and dGPU/GPUVM paths... one thing I forgot to mention there was the dGPU/GPUVM paths work well even on HW that is limited to 40-bit GPU addresses.

[drSeehas]

... Carrizo-L is CI, Stoney Ridge is VI. Both support IOMMUv2, ...

Are you sure?
AFAIK Kabini and Beema support only IOMMUv1.

Where do I find a good source for the differences between IOMMUv1 and IOMMUv2?

[bridgman]

I thought Kabini was v1 and Mullins/Beema/Carrizo-L was v2 but that's just based on documentation (and what I remember from a couple of years ago) not from actually exercising the v2 functionality.

Latest public IOMMU docco is here...

http://support.amd.com/TechDocs/48882_IOMMU.pdf

The main differences between v1 and v2 are:

- the addition of ATS 1.1 / PRI support, which allows a PCIE device with ATC to access unpinned system memory
- ability to use same page table format (same page tables in fact) as CPU rather than requiring separate tables

My understanding is that v1 functionality can run alongside the new features in v2.

I haven't found a lot of accessible documentation online; Tom's slides are good and I thought there was one other Xen-related deck I haven't found yet. Start at slide 10:

http://www.slideshare.net/xen_com_mg...10tomwolleramd

[drSeehas]

... the addition of ATS 1.1 / PRI support, ...

As Address Translation Service and Page Request Interface are optional on a peripheral, it is not a good idea to rely on it.

Edit:
I am looking for a table which IOMMU version devices (dGPU and APU) are supporting.

[bridgman]

AFAIK the v1 functionality is usually invisible to the device (there is apparently an ATS/ATC option for caching translations but I haven't seen it used much) so any device should support it... v1 functionality is basically a firewall for the PCIE bus, although it also does some other useful things like mapping high physical memory addresses to low bus addresses for peripherals with limited addressing range.

I know Tahiti includes v2 (ATC using ATS/PRI) support, not sure about the rest of the GCN family but I imagine most of them do.

The only thing that would rely on ATS/PRI support would be the device driver and it knows what HW features are available on the device.

EDIT - I just looked at the thread title, how did we get onto this discussion in this thread ?

[drSeehas]

... I just looked at the thread title, how did we get onto this discussion in this thread ?

My fault:

https://www.phoronix.com/forums/forum/phoronix/general-discussion/854429-sfc-considers-combining-zfs-with-linux-a-gpl-violation?p=868294#post868294

I asked in another thread about AMD CPUs not supported by Xen.