On Fri, Jun 7, 2019 at 4:16 PM Philipp Kern <pk...@debian.org> wrote: > > On 6/6/2019 8:09 PM, Aron Xu wrote: > > Key interest in the thread is getting some insights about how to deal > > with the awkward situation that affects ZFS experience dramatically - > > Linux will remove those symbols in LTS kernel release, although > > in-kernel symbols are never promised to be stable. I've been in touch > > with ZoL upstream to listen to their plans and wishes, so that we > > (Debian ZoL people) can take actions that serve best for our users and > > community. > > I will note that in terms of prior art Debian has in the past always > prioritized freeness over performance. Whenever there are binary blobs > involved to improve performance, we opted not to ship them unless they > could be reproduced using free software and have their source included. > > Of course in that case people were still free to install the binary > blobs from non-free, assuming that the blob was in fact distributable. > This would not be the case here. But crippling the performance would be > indeed an option, even though this would make Debian much less relevant > for ZFS deployments and people would just go and use Ubuntu instead. >
I agree that we usually prefer free-ness and universal-ness over performance, you know Mo Zhou in this thread is actively pushing deep learning stuff into Debian and he is discovering a lot of way to exploit better performance while not being too invasive to existing culture. Also I'd like to mention, it could be a widespread misunderstanding that "when something is incompatible with GPL/Linux then it's likely non-free". ZFS itself is free and open source software, I don't think it's comparable to non-free blobs. Even further, it's distributed in the form of dkms source and theoretically not in Debian (contrib) to save people of Software Freedom Conservancy from being upset about losing their position of Linux GPL enforcement. > Still, crippling performance would still provide a lever and motivation > for upstream to come up with a way to disable the FPU on every supported > architecture one by one (if only on the most important one), even if > it's brittle and hacky. I personally wonder why a kernel which provides > a module interface does not provide a way to save FPU state, but alas, > they made their decision. > It is hard to interpret why Greg KH would like to disallow access to hardware features and I don't think I'm at the position to comment. There is another way around at implementation side though, when a kernel thread is going to use FPU, preempt is usually (if not always) disabled, so it's still possible to make use of those registers without messing up with all the kernel states. But it's still weeks to go before being able to have an PR upstream. We are confident to have a version of ZFS that could make use of vector instructions in several months, but it could be hardly possible to merge back to buster stable updates, so that we'll have to recommend people using stretch-backports which is fine. > In the great scheme of things doing things the slow way has forced > certain progress to happen in the past when it was painful enough. The > question I wonder is if we are relevant enough here to push the needle > or if essentially all other distributions (say Ubuntu) will dare not to > follow upstream here and carry a patch forever. > IIRC all major distributions have a series of downstream maintained patches being carried for very long time, like the aufs4 patchset in Debian kernel. But this is not the case for the FPU one because it's not technically complex but people tend to avoid something supposed to lead to heated discussion in some regard. Regards, Aron
