Six Features Not In The Mainline Linux 5.6 Kernel

[duby229]

Please use your fantasy before contradicting people. It's rude.

This one is an idiom: A writer thread posts the semaphor after writing (involving one of multiple mutexes); the reader blocks on the semaphor, and then locks each mutex in turn to find the newly written item, before it goes back to blocking on the semaphor.

The problem is that blocking is really hard to do and not just anybody should even try. Almost everyone that try's is going to screw their codes performance. There might be at an absolute maximum maybe 100 people globally that can do it right. And that's exactly why it should be implemented in the kernel so that everyone has an interface that is known good.

EDIT: Plus, you know, process management..... The other reason these futex modifications should be in kernel.... Just look at native game ports to linux as the perfect example of this problem with blocking that these kernel patches could have prevented if they existed at the time they were ported. No need to do broken blocking if known good blocking already exists....

[indepe]

The problem is that blocking is really hard to do and not just anybody should even try. Almost everyone that try's is going to screw their codes performance. There might be at an absolute maximum maybe 100 people globally that can do it right. And that's exactly why it should be implemented in the kernel so that everyone has an interface that is known good..

The proposed kernel interface will not be an interface for "everyone". If there ever will be an application-level interface, it will be in userspace, for example in glibc. The interface they want is for the do-it-yourself people who you think there are only 100 of.

EDIT: Plus, you know, process management..... The other reason these futex modifications should be in kernel.... Just look at native game ports to linux as the perfect example of this problem with blocking that these kernel patches could have prevented if they existed at the time they were ported. No need to do broken blocking if known good blocking already exists....

I don't know why you are so sure that this solves a problem that doesn't already have valid solutions. I can't tell from your post, and I can't tell why the proposers think that, from the descriptions provided.

[duby229]

The proposed kernel interface will not be an interface for "everyone". If there ever will be an application-level interface, it will be in userspace, for example in glibc. The interface they want is for the do-it-yourself people who you think there are only 100 of.

I don't know why you are so sure that this solves a problem that doesn't already have valid solutions. I can't tell from your post, and I can't tell why the proposers think that, from the descriptions provided.

I just don't think blocking should be done in userspace, almost nobody is good at it. Process management and memory management exists in kernel for a good reason and that reason -is- that almost nobody is good at blocking. And now we live in an age where processors can have dozens or even hundreds of cores, and even situations where cores and memory banks are not anywhere physically near each other. The bottom line is that blocking is hard and getting much harder.

EDIT: Just let the process manager and memory manager do its thing, it's just about guaranteed the linux kernel can do process management better than you.

[indepe]

I just don't think blocking should be done in userspace, almost nobody is good at it. Process management and memory management exists in kernel for a good reason and that reason -is- that almost nobody is good at blocking. And now we live in an age where processors can have dozens or even hundreds of cores, and even situations where cores and memory banks are not anywhere physically near each other. The bottom line is that blocking is hard and getting much harder.

EDIT: Just let the process manager and memory manager do its thing, it's just about guaranteed the linux kernel can do process management better than you.

Maybe it isn't clear what "userspace" refers to. When you use a mutex or a semaphore on Linux, chances are you are using an implementation that is for a significant part in userspace. That doesn't mean you are using something that was done by people who aren't good at it. In fact, "futex" is short for "fast userspace mutex". But actually it is just the basic building block that can be used to implement a fast mutex in userspace. In itself, it is not the kind of thing that you know as an application-level mutex. It is more like a very simple semaphore, without a counter or any value at all, except for the short moment wait is called. It can be used to implement a fast semaphore in userspace just as well. (But "fuphore" wouldn't sound as good. )

If the userspace implementations internally use a futex, as they already do, the kind that already exists, then the "blocking" part is already done by the kernel. The proposed feature doesn't change that.

Nobody is, or was, talking about implementing the "blocking" part, the one you are apparently concerned about, in userspace.

[duby229]

Maybe it isn't clear what "userspace" refers to. When you use a mutex or a semaphore on Linux, chances are you are using an implementation that is for a significant part in userspace. That doesn't mean you are using something that was done by people who aren't good at it. In fact, "futex" is short for "fast userspace mutex". But actually it is just the basic building block that can be used to implement a fast mutex in userspace. In itself, it is not the kind of thing that you know as an application-level mutex. It is more like a very simple semaphore, without a counter or any value at all, except for the short moment wait is called. It can be used to implement a fast semaphore in userspace just as well. (But "fuphore" wouldn't sound as good. )

If the userspace implementations internally use a futex, as they already do, the kind that already exists, then the "blocking" part is already done by the kernel. The proposed feature doesn't change that.

Nobody is, or was, talking about implementing the "blocking" part, the one you are apparently concerned about, in userspace.

But that's not how Windows works. Which is why I mentioned game ports and is exactly the problem these futex modifications in kernel will address. Windows doesn't actually have a real true process manager, it's much more like a glorified time slicer.... And it's this dilemma that these kernel patches can address so that game ports from windows don't -have- to worry about blocking in userspace.

EDIT: This is -thee- reason why most game ports to linux perform slower than their windows counterparts.

[indepe]

But that's not how Windows works. Which is why I mentioned game ports and is exactly the problem these futex modifications in kernel will address. Windows doesn't actually have a real true process manager, it's much more like a glorified time slicer.... And it's this dilemma that these kernel patches can address so that game ports from windows don't -have- to worry about blocking in userspace.

I haven't seen the Windows implementations but I'd be sure that mutexes and semaphores, at least the fast versions if there are any, are also for a significant part implemented in userspace. The best I know that's a requirement for optimal performance. We maybe just don't know that because it's not open source. Or there, the word "userspace" is perhaps defined differently.

[duby229]

I haven't seen the Windows implementations but I'd be sure that mutexes and semaphores, at least the fast versions if there are any, are also for a significant part implemented in userspace. The best I know that's a requirement for optimal performance. We maybe just don't know that because it's not open source. Or there, the word "userspace" is perhaps defined differently.

Yes, it certainly is, Windows is a true microkernel. Basically everything is userspace.

[c117152]

I don't think it's nice hardware, but maybe it's not so common because it might be expensive.
This is a high-end motherboard where this adapter can be found:

https://asrock.com/MB/AMD/X470%20Taichi%20Ultimate/index.asp

I don't want to buy a $10 usb dongle to have another USB port occupied for this and have weak signal when motherboard with integrated wifi and external antennas exist.

High-end in computing, especially AMD let alone running linux, is niche. And wireless desktops/workstations... Well, just consider yourself lucky it works at all.

[indepe]

Yes, it certainly is, Windows is a true microkernel. Basically everything is userspace.

Upon re-reading your answers, I'm not sure anymore if this means that we agree that the "blocking" part should be in the kernel, and the non-blocking part in userspace.

[duby229]

Upon re-reading your answers, I'm not sure anymore if this means that we agree that the "blocking" part should be in the kernel, and the non-blocking part in userspace.

Well, at minimum we need to agree that process management should never be done in userspace on linux. On windows you -have- to, but on linux definitely no. How windows time slices processes compared to how linux schedules processes are two very different concepts. It's the whole reason why game ports to linux perform worse than their windows counterparts. There needs to be a way to deal with it in kernel and that's exactly what these futex patches do.