Proposed futex2 allows Linux to mimic the NT kernel for better Wine performance

https://lkml.org/lkml/2021/4/27/1208

by marcodiego • 5 years ago

389 196 5 years ago

Bummer that this doesn’t seem to support or explicitly plan for the proposed FUTEX_SWAP operation[1] (unless I’m missing it).

[1] https://lwn.net/Articles/824409/

dundarious• 5 years ago

I haven't read anything about FUTEX_SWAP since Aug 2020. Do you know is there ongoing progress?

maxfurman• 5 years ago

Can someone please ELI5 what is a futex? Is it like a mutex?

hulitu• 5 years ago

As far as i remember a futex is a fast mutex

corbet• 5 years ago

See https://lwn.net/Articles/823513/ for a look at both the old and proposed new futex interfaces.

achernya• 5 years ago

futex is a Fast Userspace muTEX. It's the syscall to help implement a mutex when there are two or more threads waiting on the lock to let other processes/threads schedule and do useful work during the wait.

hyperman12• 5 years ago

Futex stands for fast userspace mutex. It is a basic building block for implementing a mutex (amongst others).

Afaik, if locking a mutex succeeds, futexes avoid a context switch to and from the kernel. The fast path happens completely in userspace. Only when a mutex lock causes a thread to sleep, the kernel is needed. All of this improves mutex performance.

There are other locking primitives than mutexes, and the current futex interface is not optimal for implementing common windows ones. Hence this proposal.

xxs7• 5 years ago

"context switch to and from the kernel"

This is a common misconception, a "context" switch is a lot more expensive than a "mode" switch that goes from user mode to the kernel mode (and back).

Of course, if the futex has to wait, it'd be a context switch for real.

ece• 5 years ago

ESYNC is the way this is currently done, it's hit and miss in that it doesn't work unless the number of open files is set high enough for some games. It's also slower than this proposal.

gpderetta10• 5 years ago

A futex is an ephemeral list of waiting threads or processes keyed on an address. It can be used to implement any synchronization or signaling primitive, like mutexes, condition variables, semaphores, etc.

tialaramex4• 5 years ago

This is a really nice insight into the kernel's model of what's going on. It's probably not the best way for an absolute beginner to think about why they want this, but it's much better than some of the other explanations if you have trickier technical or performance questions, and it makes it obvious why it's clever and why you need the OS kernel to actually implement it.

whoisburbansky• 5 years ago

It's a primitive that lets you build mutexes; you've got an atomic integer in userspace, attached to a wait queue in kernel space. Eli Bendersky has a pretty good rundown: https://eli.thegreenplace.net/2018/basics-of-futexes/

bogomipz7• 5 years ago

This is a good post thanks. One thing confuses me is that these two sentences seem to contradict each other:

"Before the introduction of futexes, system calls were required for locking and unlocking shared resources (for example semop)."
"A user-space program employs the futex() system call only when it is likely that the program has to block for a longer time until the condition becomes true"

The first indicates futexes are an improvement because they avoid the overhead of system call but the second states that futex() is a system call.

Is this similar to how a vDSO or vsyscall works where a page from kernel address space is mapped into all users processes? In other words is it similar to how gettimeofday works?[1]

[1] https://0xax.gitbooks.io/linux-insides/content/SysCall/linux...

DSingularity• 5 years ago

Okay, consider a multi-threaded program. These programs have multiple threads running on multiple cores. Sometimes you want to coordinate the execution of multiple threads in such programs. A common example is when a thread is in a "critical section" where it is only safe for one thread to access/modify state. Sometimes threads will have to wait for each other. This is where the futex comes in. Instead of the thread to wait while using the processor it can tell the OS that it needs to wait for this futex to become free. The OS will then suspend the thread and find another one to schedule in its place.

bogomipz7• 5 years ago

Ah Interesting. So is the concept of futex() similar to how a process in kernel mode will yield the CPU by putting itself on a wait_queue and call the schedule() function before it issues an I/O request then?

I realize that one is userspace and the other kernel but would the above be the right mental model?

ROARosen2• 5 years ago

Can someone please ELI5 what is a mutex?

marcodiego6• 5 years ago

Mutex is named after "mutual exclusion" a primitive that is used to guarantee that some parts of code will run exclusively, never at the same time. This is important for good performance and synchronization on multiple threaded programs.

__init2• 5 years ago

(Edited because I transposed "mutex" and "semaphore" in my mind.)

A mutex is a lock -- if multiple users attempt to access a resource simultaneously, they each attempt to acquire the lock serially, and those not first are excluded (blocked) until the current holder releases the lock.

Mutexes are typically implemented with semaphores:

First a more developer-oriented explanation (because I imagine that's what you really want):

A semaphore locks a shared resource by implementing two operations, "up" and "down". First, the semaphore is initialized to some positive integer, which represents how many concurrent "users" (typically threads) can use that resource. Then, each time a user wants to take advantage of that resource, it "down"s the semaphore , which atomically subtracts one from the current value -- but the key is that the semaphore's value can _never_ be negative, so if the value is currently zero, "down"ing a semaphore implies blocking until it's non-zero again. "Up"ing is just what you'd imagine: atomically increment the semaphore value, and unblock someone waiting, if necessary.

Semaphores are generally seen as a fundamental primitive (one reason being that locks/mutexes can be implemented trivially as a semaphore initialized to one), but they also have broad use as a general synchronization mechanism between threads.

For a true ELI5 of semaphores (I enjoy writing these):

Imagine everyone in class needs to write something, but there are only three pencils available, so you devise a system (a system of mutual exclusion, per se) for everyone to follow while the pencils are used: First, you note how many pencils are available -- three. Then, each time someone asks you for one, (which we call "down"ing the semaphore) you subtract one from the number in your head and give them a pencil. But if that number is zero, you don't have any pencils left, so you ask the person to wait. When someone returns and is done with their pencil, you hand it off to someone waiting, or, if nobody is waiting, you add one to that number in your head and take the pencil back ("up"ing the semaphore). It's important that you decide to only handle one request at a time (atomicity) -- if you tried to do too many things at once, you might lose track of your pencil count and accidentally promise more pencils than you have.

hyperman12• 5 years ago

A mutex is the software equivalent of the lock on your toilet door. There is a zone in your code where only 1 thread at a time is allowed. So before entering, you lock the mutex. Now either you are allowed in or are added to a set of waiters. When you leave, you unlock the mutex, and 1 other waiter is allowed to enter.

This sounds easy, but is in practice wrought eith peril. You need high performance, not waste too much cpu time on sleepers, some notion of fairness when you have lots of waiters, minimal memory usage, etc...

xxs7• 5 years ago

My ELI5 version of that locking mechanism, e.g. mutex, uses a toilet and the disaster if multiple people try taking the dump at the same time.

Iwan-Zotow• 5 years ago

it is thing behind/inside mutex. It is making uncontested mutex acquire/release ops pure userspace thingy.

brandmeyer• 5 years ago

The best introduction is probably the original presentation paper from 2002.

Fuss, Futexes, and Furwoks: Fast Userlevel Locking in Linux

https://www.kernel.org/doc/ols/2002/ols2002-pages-479-495.pd...

Another great paper that came after some additional experience by glibc developers:

Futexes are Tricky, by Ulrich Drepper

https://www.akkadia.org/drepper/futex.pdf

MaxBarraclough• 5 years ago

I see Drepper resisted the urge to pluralise futex to futices.

bogomipz7• 5 years ago

I just found this article which I think is really helpful as it has some good historical context as well:

"Detailed approach of the futex"

http://www.rkoucha.fr/tech_corner/the_futex.html

a-dub3• 5 years ago

what's the nt api call called? WaitForMultipleObjects? takes me back 20 years just thinking about it...

Joker_vD2• 5 years ago

By the way, hearing about futex implementation and their API considerations should also bring everyone about 20 years back.

dboreham• 5 years ago

The NT api would begin ntXxxx WaitForMultipleObjects is a Win32 function.

poizan422• 5 years ago

I don't know why you are being downvoted, you are completely right. The NT api function is NtWaitForMultipleObjects. The Win32 apis WaitForMultipleObjects and WaitForMultipleObjectsEx are thin wrappers over this.

ziml77• 5 years ago

If we're being pedantic here, it's not Win32.

(Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)

Though Win32 is going to stick around for a while as can be seen in the URL for the page that's quoted from: https://docs.microsoft.com/en-us/windows/win32/apiindex/wind...

beatrobot• 5 years ago

NtXxxx or ZwXxxx

tobias3• 5 years ago

WaitOnAddress and co. But that one was added with Windows 8, so it can't take you back 20 years :)

gpderetta10• 5 years ago

WFMO is indeed the api that the new futex_waitv is supposed to help accelerate under wine.

c7DJTLrn3• 5 years ago

This might get me some angry replies, but does the feature set of Linux ever end? Will there ever be a day where someone says "you know what, Linux isn't built for this and your code adds too much complexity, let's not". It really just seems like Linux has become a dumping ground for anyone to introduce whatever they feel like as long as it passes code review, with nobody looking at the big picture.

trillic• 5 years ago

So what? This code (and most drivers, modules, additional fucntionality, etc) will only be compiled in if necessary and will only actually be run if you use the feature.

c7DJTLrn3• 5 years ago

My concern is not about what my flavor of kernel includes. It's about the size of the codebase, and whether the limited number of maintainers can keep up with the countless features being introduced.

pram• 5 years ago

That’s the beauty of open source! Just fork your own Linux and then refuse any further patches or PRs. True freedom.

dooglius• 5 years ago

No, because the Linux kernel is designed explicitly as a monolithic kernel, so as long as there is anything anyone wants to do that is "OS-like", it expects to own that.

gpderetta10• 5 years ago

this patch both cleanup existing complexity and add functionality needed for a significant use case.

thedracle• 5 years ago

I mean, the futex2 proposal has been around for over a year.

A lot of the history and discussion can be found here: https://lkml.org/lkml/2021/4/27/1208

I personally feel like the kernel maintainers have been very conservative over the years regarding the introduction of new system calls, but then again I've maybe gotten used to the trauma of being familiar with windows internals.

fullstop• 5 years ago

The BSDs are always an option.

zokula2• 5 years ago

The BSDs were an option they are becoming more moribund and less used every year.

bombcar• 5 years ago

Linus has done exactly that a few times; though usually he defines what would be needed to be merged.

Some of the changes aren't compatible with the kernel direction as a whole and so they're a separate branch. Given enough time (and if the change is major AND ends up being widely used) it may get merged in.

Those who want a specific kernel with a defined feature set often will look to one of the BSDs as a base (as often they also have reduced hardware requirements, think routers).

yarg• 5 years ago

As a relative layman, this all seemed reasonable and desirable - and the fact that he integrated it with pthreads seems particularly cool to me.

NUMA awareness especially stood out as highly significant.

The new supported sizes seems nice and shiny - if well utilised, it could improve performance and capacity in general, capabilities in the low-end and scaling in the high-end.

lizknope• 5 years ago

Linus Torvalds looks at the big picture all the time. That is basically his job as he doesn't write a lot of low level code anymore.

Do you have an example of something that you consider part of the "dumping ground?"

marcodiego6• 5 years ago

Getting a new syscall on linux is hard. You'll often need user-space users before it gets accepted; that alone is hard. The linux syscall set is very small considered the breadth of cases it is used today. Compared to nt, linux syscall set is very small and well thought out.

formerly_proven• 5 years ago

Windows has around 500 syscalls, Linux around 300.

Both have several escape-hatches for arbitrary driver-userspace communication, which makes the number of syscalls pretty irrelevant. (E.g. Linux has ioctl, netlink, procfs, sysfs, ...)

GoblinSlayer• 5 years ago

Linux syscall set is very small and posix. No matter what you think, the first version is always a prototype.

rkangel• 5 years ago

with nobody looking at the big picture

As I understand it, this is exactly what Linus does. He's the final arbiter of what makes it in, and has a history of setting high level direction for how stuff should be (usually prefixed with "I'm rejecting this because").

anoncake• 5 years ago

What purpose is a general-purpose kernel not built for?

vondur• 5 years ago

I'm assuming if you build the kernel yourself, you may be able to strip out features you don't want.

broodbucket3• 5 years ago

Yep, there's loads and loads of config options. Linux isn't a big immutable blob, there's a reason it gets used in both tiny devices in supercomputers, you can build your kernel however you like.

It's not a microkernel but it does a pretty good job of being flexible for a monolithic kernel.

If you're curious, clone the kernel source and run `make menuconfig` and you can play with it yourself

Ericson23143• 5 years ago

This shouldn't be getting down-votes.

Consider the slogan "composition not configuration", Linux is squarely the latter. All the hardware, all the different use-cases, that are just added to what's mostly a monolith. You can disable them, but not really pull things a part.

Now, Linux also has some of the most stringent code review in the industry, and they are well aware of issues of maintainability, but fundamentally C is not a sufficiently expressive language for them to architect the code base in a compositional manner.

What really worries me is that as the totality of the userland users an increasingly large interface to the kernel, it will very hard to ever replace linux withsomething else when we do have something more compositional. I am therefore interested, and somewhat working on, stuff that hopefully would end up with a multi-kernel NixOS (Think Debian GNU/kFreeBSD) to try to get some kernel competition going again, and incentivize some userland portability.

Note that I don't think portability <===> just use old system calls. I am no Unix purist. I would really like a kernel that does add new interfaces but also dispenses with the old cruft; think Rust vs C++.

fabianhjr• 5 years ago

Consider the slogan "composition not configuration", Linux is squarely the latter. All the hardware, all the different use-cases, that are just added to what's mostly a monolith. You can disable them, but not really pull things a part.

Linux is a Monolithic Kernel, sounds like you are more interested in Microkernels. https://www.wikiwand.com/en/Microkernel

One microkernel alternative could be Redox-OS: https://www.wikiwand.com/en/Redox_(operating_system)

oalae5niMiel7qu• 5 years ago

but fundamentally C is not a sufficiently expressive language for them to architect the code base in a compositional manner.

Plan 9 would like to have a word with you.

DSMan195276• 5 years ago

Features get rejected all the time, even some pretty substantial ones. That said I think there's two things to keep in mind:

1. If someone is willing to take the time to develop and submit something to the kernel, it probably has some redeeming factors to it. The original idea or code might not get merged, but something similar to meet those needs likely can be if it's really something the kernel can't do.

2. The modularity of the Linux Kernel build system means that adding new features doesn't have to be that big of a deal, since anybody who doesn't want them can just choose not to compile them in. It's not always that simple, but for a lot of the added features it is.

joppy• 5 years ago

I don’t think this is an achievable goal for a kernel, since it has strictly more permissions than user code. There are some parts of user code that simply cannot be made faster by changing how they’re written: no amount of rewriting in Rust/C/C++ will help if the relevant kernel primitives are not there. The kernel must move with the times, and incorporate new features as they are (tastefully) decided upon.

penagwin• 5 years ago

There are pieces of linux - say the networking - that already don't meet many people's use cases. People seem to like BSD for certain networking stuff due to differences in the respective networking stacks.

zokula2• 5 years ago

People seem to like BSD for certain networking stuff due to differences in the respective networking stacks.

Is that why *BSD has lower market share for servers and other networking equipment than it did 15 years ago?

slaymaker1907• 5 years ago

I think that will be the day somebody comes and creates a new FOSS kernel which gets rid of mostly unused legacy code. The problem with this sort of stuff is that it is hard to know what abstractions will actually be useful before said abstractions are available.

I don't think anyone in their right mind would design the IndexedDB APIs the way they are with the background of modern JS. It would certainly be promise based and I think there would be a better distinction between an actual error with IndexedDB vs just an aborted transaction. It's also extremely confusing about how long you can have transactions ongoing. I suspect they would replace the nonsensical autocommit behavior of transactions currently with some sort of timeout mechanism. There is way too much asynchronous code out there these days to rely on the event loop for transactions committing.

Linux is honestly pretty clean as far as outdated abstractions go, but Windows is definitely very guilty of keeping around old outdated abstractions. Having execution policies for PowerShell while batch scripts get off scotch free is really strange. These restrictions would only make sense if Windows didn't let users run VBScript, Batch, etc. Can anyone tell me how running a PowerShell script is inherently more dangerous than VBScript or Batch scripts?

stjohnswarts• 5 years ago

That's a fair criticism but the kernel is very modular and the legacy stuff that no one will maintain gets cut all the time, so I think it's all a fair tradeoff. I'm not angry, just pragmatic because if you don't evolve you die, look at how much market share BSD has lost over the past 15 years

__d• 5 years ago

I think it's hard to blame BSD's (collective) loss of market share on their reluctance to add system calls, or even their pace of evolution more generally.

Are there some specific evolutions that you think Linux adopted, and eg. FreeBSD didn't, that were/are crucial to Linux' now overwhelming dominance?

marcodiego6• 5 years ago

Artificial benchmarks show a 4% improvement in some cases, which is huge. There aren't many tests to demonstrate the improvements on common use cases but there are already reports of subjective improvements with games having less stutter: https://www.phoronix.com/forums/forum/phoronix/latest-phoron...

savant_penguin• 5 years ago

Really curious, why is 4% improvement huge?

k1rcher• 5 years ago

This is interesting. Does anyone know of previous figures on Windows virtualization improvement?

marcodiego6• 5 years ago

Because you don't have to change one line of your previously running software to get this benefit or replace your hardware. Of course, will need a new version of the kernel and wine, but that is a matter of time to hit distro repositories. Also, consider that this will accumulate when combined with new user space libs, servers, compilers, drivers... Software will improve without any change just by keeping your distro updated.

Yes, a 4% improvement is huge.

sp332• 5 years ago

Well, it's a relative measure. There's been a ton of optimization already. All the low-hanging fruit is gone. It's probably been a long time since a single optimization gained 4%.

tombert• 5 years ago

I don't know much about Wine, but I'm speaking in generalities, but I've worked jobs where we spend weeks to get <10% performance increases. Very often that last bit of optimization is the hardest part.

chalst2• 5 years ago

"Huge" means different things in different contexts. A compiler optimisation that delivered a 4% increase in speed for a whole class of well-tuned C programs would be regarded as huge by people who follow compiler technology, but would not strike most users of computers as a big deal. I take it "huge" is meant in this sense of extraordinary within a class of potential improvements.

If you can accumulate a series of 4% improvements, then even the computer consumer will start to see the significance.

fefe232• 5 years ago

Intel Xeons have huge price differences at the top tier for relatively minor performance differences.

So if you get 4% for free here, that could mean hundreds of dollars savings compared to having to buy the next tier hardware. Multiplied by the number of Intel customers.

4% could mean the difference between "I can still use my old computer" and "I need to buy an upgrade".

phkahler• 5 years ago

- For requeue, I measured an average of 21% decrease in performance compared to the original futex implementation. This is expected given the new design with individual flags. The performance trade-offs are explained at patch 4 ("futex2: Implement requeue operation").

It's not clear that this is a win overall. But hey, if Windows games run better under wine...

derefr• 5 years ago

Better yet, since Wine is there to serve as a “smart” shim, it can offer a launch config parameter for the app, that will get Wine to point its futex symbols at its previous userland impl. (Sort of like the various Windows compatibility-mode flags.) So even Windows apps that do tons of requeues (and so presumably would be slowed down by unilaterally being made to do kernel futexes) would be able to be tuned back up to speed. And distros of Wine that provide pre-tuned installer scripts for various apps, like CrossOver, can add that flag to their scripts, so users don’t even have to know.

gpderetta10• 5 years ago

IIRC glibc stopped using requeue a while ago for cobdution variables wait morphing, so maybe requeue is not a hugely important use case anymore.

Denvercoder9• 5 years ago

The old interface will remain available, so if requeue performance is important, you can keep using that. Also at least one kernel maintainer considers requeue to be historical ballast [1], so it's probably not used much anymore.

[1] https://lwn.net/ml/linux-kernel/87o8thg031.fsf@nanos.tec.lin...

xxs7• 5 years ago

4% performance improvement for up to 800 threads.

800 threads on similar WaitForMultipleObject is already a horrific design if you even remotely care about performance. The only viable case for 800 threads (and wine) would be blocking IO which is an extremely boring one.

usefulcat• 5 years ago

Sure, but that's irrelevant for wine, which doesn't get to choose how the things that it's running (e.g. games) are implemented.

asveikau2• 5 years ago

IIRC, WaitForMultipleObjects can only block on 63 handles. 800 threads blocked on 63 handles seems pretty weird.

zamalek• 5 years ago

The use case lies in the Wine implementation of the Windows NT interface WaitMultipleObjects.

This can't only be a win for emulating Windows, surely (future) Linux native code could benefit from this too?

CoolGuySteve• 5 years ago

Linux's answer is io_uring with eventfd. I've noticed it has higher latency than WaitForMultipleObjects though. I've had a hard time getting the 99th percentile latency below 5usec.

It would be nice if io_uring polling had a futex-like feature that spinned in userspace rather than having to syscall io_uring_wait every time. I feel like that feature would be more universal than futex2.

Adding an atomic int somewhere in the userspace would add ~100ns in the kernel path but save many microseconds in the userspace-spin path during high contention so it seems like a win to me.

the8472• 5 years ago

My understanding of io_uring is that you can already poll the CQ with atomics without any syscall. io_uring_enter() is only needed to inform the kernel that new SQ entries exist and that too can be replaced by polling via IORING_SETUP_SQPOLL in privileged processes.

vardump2• 5 years ago

Spinning consumes a lot of power, so I'd guess one would only want to do that when very low latency is truly required. At least I'd certainly wouldn't want it to be the default for the generic case.

Of course a low latency option should also exist for those cases that require it and currently that pretty much means spinning.

guenthert• 5 years ago

I've had a hard time getting the 99th percentile latency below 5usec.

Can we take a moment to appreciate how mind-blowing astonishing a 99th percentile latency in the us range is given a general-purpose, multi-user OS with support for virtual memory is?

vardump2• 5 years ago

This can't only be a win for emulating Windows, surely (future) Linux native code could benefit from this too?

That would certainly help porting Windows software to Linux.

aasasd7• 5 years ago

I lowkey have to wonder why Linux seemingly goes all-in on monster functions that implement a variety of operations depending on the arguments (as far as I can see from casual encounters). In my experience, such code often both reads poorly on the calling side and looks very messy inside. I came to prefer making distinct functions that spell out their intended action in the names. Windows apparently went the same path.

E.g.: syscall doesn't accept multiple handles and other bells and whistles? Well duh, it's not supposed to—just make a new one that does.

Of course, it's probably too late to change this design choice now...

whatshisface7• 5 years ago

I can only offer speculation, but it could be that the alternative, a complicated API that requires several subsequent calls to use, is seen as more of a risk for bad programming and state mis-tracking. We definitely don't want programs leaving the kernel in a bad state by calling the first half of a sequence of syscalls then later on getting distracted or crashing and never finishing it. A single call gives atomicity guarantees that are otherwise hard to come by in languages without state tracking primitives like futures or borrow checked references.

Another thing to remember is that in C, it's easier to make a call more specific, by hardcoding values than it is to make it more general, by picking between variants in a branch. I can see programmers wishing the API was more dynamic while writing a giant if-else tree to select the appropriate version of the syscall, but the opposite problem, when the same invocation is always needed but the API takes a lot of dynamic options, is not as bad because it is easy to write a bunch of literals in the line that calls the function. (If C had named arguments that approach would be almost flawless.)

aasasd7• 5 years ago

I don't see how `an_op_syscall(param)` is ‘more complicated’ or requires more calls or state than `a_syscall(OP_NAME, param)`.

marcodiego6• 5 years ago

Probably main reasons are:

  - Syscalls are not designed to be called directly from end-user programs. Instead lower level libs calls syscalls.

  - Getting a syscall accepted is a long and tedious proccess, so they should as general and future proof as possible.

quotemstr• 5 years ago

You're talking about the problem of multiplexer system calls. The kernel is actually moving away from that model towards one of fine grained operations.

Cloudef3• 5 years ago

What happened to NTSYNC? https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...

elynl2• 5 years ago

It's still a thing! kernel: https://repo.or.cz/linux/zf.git/shortlog/refs/heads/winesync wine: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/fastsync2

They decided to rename it since the kernel maintainers don't want NT interfaces and having NT in the name doesn't help

Cloudef3• 5 years ago

Thats good to hear. Darling devs also went with kernel module approach. Its weird wine devs did not do the same until now. Wineserver is nice but as we see, its sometimes impossible to do accurate emulation of some apis there.

https://docs.darlinghq.org/internals/basics/system-call-emul...

monocasa5• 5 years ago

Too bad bpf isn't allowed for non root yet. A bpf futex program like xok's wake programs would be more general, and way nicer.

fefe232• 5 years ago

What are you talking about?

I have been using bpf in seccomp for non-root for years.

Maybe your distro patched that out. The stock kernel allows bpf for non-root.

monocasa5• 5 years ago

Sort of... there's been push back in the post spectre days of expanding non root usage of BPF. Right now, a subset of trace programs and seccomp are allowed for non-root, but that hasn't expanded since 2016. Everything else requires CAP_SYS_ADMIN.

They would probably remove those too if the balance of Linux didn't put "don't break user space" higher than "defense in depth security".

Shadonototro4• 5 years ago

if linux people focused on offering compelling ecosystem for app/game distribution, they wouldn't need to bloat their os with slow and bloated emulators like wine

the reason why linux isn't gaining shares on steam anymore is because valve openly said linux has no ecosystem and is forced to emulate windows -- proton

ijlx• 5 years ago

Wine is not an emulator, it is a compatibility layer for Windows system calls on a Unix-like platform. If something runs on wine, the performance overhead should be unnoticeable/very small for the typical user.

chungy2• 5 years ago

Ironically, it seems quite often that Wine runs apps/games faster than Windows does.

encryptluks23• 5 years ago

A compatibility layer wouldn't require that you essentially emulate the same file system layout, registry and functionality. It is basically emulating a Windows environment.

fnord77• 5 years ago

w.i.n.e = Wine Is Not an Emulator

Shadonototro4• 5 years ago

do not trust what people say they are

define people by what they do

that works with software too

broodbucket3• 5 years ago

The alternative is expecting companies to make native ports for what would be less than 1% of their userbase - and the handful that have done so haven't done it well, and even if they did it well it wouldn't change any outcomes for them.

Before Wine actually got good, the few "native" ports we had of major games on Linux were poorly optimised and often worse than just running the Windows versions in Wine.

Sometimes you gotta take what you can get. Valve's approach to invest in Wine means I don't need to dual boot any more. Native games are the cherry on top.

the reason why linux isn't gaining shares on steam anymore

Did anyone ever think Linux had any kind of comparable gaming ecosystem? lol

Valve invests in Linux as a safety net in case Microsoft ever flicks a switch and forces all game distribution through the Windows Store or similar.

Shadonototro4• 5 years ago

The alternative is expecting companies to make native ports for what would be less than 1% of their userbase - and the handful that have done so haven't done it well, and even if they did it well it wouldn't change any outcomes for them.

Valve decided to seek short term gains instead of thinking of a long term strategy by working with linux people to develop a nice ecosystem with libraries / drivers / app distribution

They could collaborate with Epic/Unity to facilitate linux builds

Valve went selfish and the result is here, linux share isn't growing, despite massive efforts from microsoft to kill themselves with vista, windows 8, and window 10 massive spyware drama and now the updates that break gaming

What if windows 11 is again a free upgrade and completely breaks wine? by introducing massive architecture changes

That'll be the death of wine and linux gaming, because no thought went into securing a nice and flourish ecosystem

twoodfin• 5 years ago

Unclear to me from the writeup: Would it be possible to implement the original futex() API on top of futex2() or is Linux doomed to preserve most of two complete futex implementations?

guipsp• 5 years ago

Would it be possible? Probably yes, but not performant.

nwmcsween• 5 years ago

A bit OT but I don't understand why kernel interfaces are single purpose vs a data-driven api, it seems like such a wasted opportunity to optimize and to have a fluid api

jwilk• 5 years ago

I find the lore.kernel.org UI much nicer:

https://lore.kernel.org/lkml/20210427231248.220501-1-andreal...

Proposed futex2 allows Linux to mimic the NT kernel for better Wine performance

Related Stories