It's great to see all these new features entering the kernel. Here are a couple of other things I've seen in recent changelogs:
- The 5.4 kernel can use CIFS as a root filesystem, meaning CIFS can replace NFS for diskless boot.
- The 5.3 and 5.4 kernels both include prep for merging PREEMPT_RT into mainline. This will be a fantastic addition that benefits embedded Linux nerds like me.
Currently the Linux kernel disables preemption inside spinlocks and interrupt handlers, and these code sections are not necessarily carefully written to be short and constant-time, so you can in theory get in a situation where all cores are running spinlock or interrupt handler code from low priority threads for arbitrarily long times, preventing higher priority realtime threads to run (which in practice means that whatever hardware you are controlling will be uncontrolled, and thus your self-driving car, rocket, plane or industrial machine might be destroyed).
The PREEMPT_RT patch solves this by reimplementing all kernel spinlocks as mutexes with priority inheritance that are fully preemptible and all interrupt handlers as preemptable threads.
The result is that if you have a bunch of real-time process/thread that do not make system calls, it's guaranteed that in a bounded amount time the highest priority set will be running.
If you do however make system calls (or even if you cause page faults because you didn't call mlockall() and accessed non-mlocked memory), with the exception of some system calls that provide better guarantees, then you can still have kernel spinlock contention with other threads that may hold the same spinlock for an unbounded amount of time, so the system is more limited than dedicated real-time OSes that are careful about this.
> Will these kernels become obsolete/unnecessary with the merge?
If it merges, sure. It's nice to see it may be getting close.
> What about BFQ, is it going to be merged at the same time too?
BFQ merged a couple of years ago.
> This patchset has been existing for a long time. What prevented an earlier merge?
It's been scary in the amount of things it touches and the amount of semantics it changes. It's a big change in mindset. Many drivers have been broken or simply unsupported at times on the preempt-rt branches.
More and more of the underlying infrastructure has made it in over the past couple years.
> Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"?
It aims to turn Linux into a real-time OS. The preempty patchset aims to give faster response times but the main focus is to remove all unbounded latencies - for example, situations where the delay can vary depending on other factors.
It's not strictly true that the rt-patchset is meant to give faster response times. It provides bounded response times. You get a guarantee that some code can run within the time frame that you specify. That's not necessarily faster.
I was at a meeting with people that were doing signal processing in "embedded" environments. They said the patch slowed them down a lot. They got better performance and more determanism even, by pinning processes to cores using prior knowledge.
Having preemption throughout the whole kernel helps with everything Low-Latency whether on desktop, mobile or server systems; it's not limited to the traditional real-time use case, although it might obviously help there as well to some extent.
The above is for kernel 5.4, as the patchset for 5.5 doesn't exist at the time of this post.
After applying the patches, you'll want to run "make nconfig" or "make menuconfig" and search for CONFIG_PREEMPT_RT and enable it and you should be good to go. The only downside in my experience is Virtual Box doesn't work with the -rt kernel as of right now, so I can't use it as my daily driver. It is a my preferred kernel though for gaming and overall desktop use. I use a custom low-latency kernel when I'm not using the -rt and it's been working well for me.
I didn't (and can't, because you replied to me) downvote, but since the downvoters are not sharing their reason, I guess I'll share my thoughts on it: I think the "quite some people at HN just enjoy downvoting" is potentially offensive as well as an overgeneralization, and they probably don't like either or both.
Aaaand downvotes for this as well, so I guess that means this is not it?
Note that your original comment is not downvoted anymore. That's the best reason not to complain about downvotes; usually it will be reversed soon enough if the comment has merit.
Early downvotes can happen through accident or randomness; all it takes is one or two people to misread your comment, or mistakenly tap the down arrow. Or they might have a valid reason for disagreeing and are in the process of writing a comment putting a different point of view.
But getting offended and defensive and editing your comment to complain about it only makes the original comment worse, and leads to an off-topic subthread like this.
Sure, edit the comment if you need to, but try to make it clearer and more informative; that's what I do if I get an early downvote and realise the comment could have been better-worded.
The down votes were because you clearly didn't understand what preemption(or that this is really about it being a realtime flag) is or add much to the conversation(mentioning anything at all that might add something, like even a bad question, "I heard people using raspberry pis for embedded, would this help?"). The downvotes on the other guy are because asking for feedback on downvotes is discouraged.
To contribute, the PREEMPT_RT has been around as a set of patches(if not this specific one, then at least some version of making linux a realtime os.). If you need to know that something will run within a specified amount of time realtime matters.
EDIT: Don't use this and think it will help performance, generally it kills throughput.
You don't talk about fight club here. I don't know who was the smartass that decided that but here we are. Stupid rule but it's their place.
And adding "offensive" every other sentence [1] assumes (for me at least - for others not that much) that you are talking about us as crybabies being easily offended.
I almost downvoted for positioning yourself as a purveyor of ethics with the implied assumption that everybody will agree with you.
But in general people around here indeed _are_ easily offended - see for example 'rzv' in this thread being downvoted for talking about this very problem. Depends of course on the thread and on the self-selected audience.
So - what can you learn from a downvote? For me is: don't debate here - HN it's not a platform suitable for debating ideas.
Random feedbackless downvoting is more and more being clearly abused to censor seemingly random and perfectly acceptable comments. The fact that talking about it is against the site guidelines only makes the problem worse. HN needs to deal with this.
> I think it's important that a site that kills submissions provide a way for users to see what got killed if they want to. That keeps editors honest, and just as importantly, makes users confident they'd know if the editors stopped being honest. HN users can do this by flipping a switch called showdead in their profile.
How can editors be "kept honest" if a bunch of their minions can just downvote users for no reason and any complaining is forbidden?
it's not "minions." Way way way back in the early days of the board we actually discussed what downvotes should mean. Argument 1 was that a vote should only indicate whether or not you thought a comment contributed to the discussion- and not indicate agreement or disagreement. This gave an indicator with a single purpose. Argument 2 was that a vote could also be used to indicate disagreement. This made one indicator mean more than one thing. Some suggested a second vote- in order to keep the indicators clear on what they were reporting.
pg eventually came down on the side of Argument 2, so voting can be either "I disagree" or "you comment is not useful."
I do agree that adding a comment when downvoting is useful to the downvotee, but alas sometimes these come off as mean or supercilious and leave a bad tone in general, spoiling the conversation (or igniting a flame war).
More and more often recently, I find downvoted comments that I thought are all perfectly useful and reasonable to the discussion. I in fact thought the downvotes were neither "useful" nor "contributing to the discussion". I would rather like to downvote the downvoters to reduce their karma and their power to perform these downvotes, but the only mechanic I have on HN to express my preference is to re-upvote the comment, which is not in fact its original intended purpose.
Rather, I would like to ignore all downvotes made by particular downvoters because I believe their judgements are highly flawed, independent of the quality of the original comment that was downvoted.
I can only speak from personal experience, so don't take this as true for everybody.
But for me, NFS has always been a colossal pain to use. The server has to run in kernel-space. Shares have to be enumerated in /etc. There are a couple of userspace options, but I've never been able to make them work reliably. Once I do get it working, it hangs all the time for no easy-to-debug reason. Also it needs multiple ports to be open, and it expects UID and GID to be the same on client and server.
CIFS has its problems for sure. But it's been pretty straightforward for me every time I've had to use it. If I was trying to set up a production-line machine to flash Linux-based devices, I'd choose CIFS every time because it's so much less hassle. And now that it's rootfs-capable, I just might be able to do it.
>A CIFS root mount currently requires the use of SMB1+UNIX Extensions
which is only supported by the Samba server. SMB1 is the older
deprecated version of the protocol but it has been extended to support
POSIX features (See [1]). The equivalent extensions for the newer
recommended version of the protocol (SMB3) have not been fully
implemented yet which means SMB3 doesn't support some required POSIX
file system objects (e.g. block devices, pipes, sockets).
As a result, a CIFS root will default to SMB1 for now but the version
to use can nonetheless be changed via the 'vers=' mount option. This
default will change once the SMB3 POSIX extensions are fully
implemented.
Who thought re-enabling uses of SMB1 was a good idea?
SMB1 has to be used any time you need the POSIX extensions, with Samba at the server side and Linux at the client side.
I find it comes up reasonably often, because Samba is so configurable. For example remapping user ids, or mapping user-group permission bits; these are hard or impossible to do in NFS, depending on available NFS server version.
As mentioned, if you like Kerberos. It's not the nicest way to do anything. Kerberos is also only supported if you (can) use NFSv4, NFSv3 doesn't support Kerberos on all clients.
I like Kerberos a good bit and I think the complexity of running an LDAP/Kerberos infrastructure is greatly over estimated, but it is disappointing that none of the theorized alternatives ever really appeared. Last I read, LIPKEY was the only serious contender and there were some security concerns that got it nixed.
And if you don't use Kerberos, NFS has no authentication. For extra credit, it's generally paired with NIS, so everyone can see everyone else's password hashes. What's not to like for an attacker?
Yes, but CIFS was a rebranding of SMB1; successive versions of SMB have just been called SMB. So first there was SMB, and then CIFS, and then (and now) it's all been just SMB. The only ones still using the term "CIFS" at this point are the Linux/Samba folks.
- The 5.4 kernel can use CIFS as a root filesystem, meaning CIFS can replace NFS for diskless boot.
- The 5.3 and 5.4 kernels both include prep for merging PREEMPT_RT into mainline. This will be a fantastic addition that benefits embedded Linux nerds like me.