How the Windows Subsystem for Linux Redirects Syscalls • Hacker News Board

Re: How the Windows Subsystem for Linux Redirects Syscalls

#151

Post by trentnelson » Thu, Jun 09, 2016, 1:54 AM UTC

binarycrusader wrote: post #135

trentnelson wrote: post #116

Earlier quoted context omitted.

I qualified it as "Linux/UNIX kernel" because I wanted to emphasize the kernel and not userspace. Solaris event ports are good, but they're still ultimately backed by a readiness-oriented I/O model, and can't be used for asynchronous file I/O.

Solaris event ports most certainly can be and are used for async I/O. I'm not sure how you can claim otherwise: https://blogs.oracle.com/dap/entry/libevent_and_solaris_even... https://blogs.oracle.com/praks/entry/file_events_notificatio... And Solaris, (unlike Linux historically at least), supports async I/O on both files and sockets. Linux (historically) only supported it for sockets. I have no idea if Linux general…

Let me rephrase it: there is nothing on any version of UNIX that supports an asynchronous file I/O API that integrates cleanly with the file system cache -- you can do signal based asynchronous I/O, but that isn't anywhere near as elegant as having a single system call that will return immediately if the data is available, and if not, sets up an overlapped operation and still returns immediately to the caller.

This isn't a terrible recap of async file I/O issues on contemporary operating systems: http://blog.libtorrent.org/2012/10/asynchronous-disk-io/

Re: How the Windows Subsystem for Linux Redirects Syscalls

#152

Post by MarkSweep » Thu, Jun 09, 2016, 2:03 AM UTC

trentnelson wrote: post #120

MarkSweep wrote: post #108

Earlier quoted context omitted.

I think IO Completion Ports [1] in Windows are pretty similar to kqueue [2] in FreeBSD and Event Ports [3] in Illumos & Solaris. All of them are unified methods methods for getting change notifications on IO events and file system changes. Event Ports and kqueue also handle unix signals and timers. Windows will also take care of managing a thread pool to handle the event completion callbacks by means of BindIoComplet…

BindIoCompletionCallback is very old, the new threadpool APIs should be used, e.g.: https://github.com/pyparallel/pyparallel/blob/branches/3.3-p... Regarding the differences between IOCP and epoll/kqueue, it all comes down to completion-oriented versus readiness-oriented. https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...

The documentation for the new thread pool APIs in Windows say that it is more performant than the old ones. Do you have any experience transitioning from the old thread pool to the new one, and if so did you notice performance differences?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#153

Post by trentnelson » Thu, Jun 09, 2016, 2:05 AM UTC

caf wrote: post #148

Since NT syscalls follow the x64 calling convention, the kernel does not need to save off volatile registers since that was handled by the compiler emitting instructions before the syscall to save off any volatile registers that needed to be preserved. Say what? The NT kernel doesn't restore caller-saved registers at syscall exit? This seems extraordinary, because unless it either restores them or zaps them then it w…

I think that's referring to the prolog/epilog convention and "homing" of parameter registers, e.g.

Frame struct ReturnAddress dq ? HomeRcx dq ? HomeRdx dq ? HomeR8 dq ? HomeR9 dq ? Frame ends

    NESTED_ENTRY Foo, _TEXT$00

    mov Frame.HomeRcx[rsp], rcx
    mov Frame.HomeRdx[rsp], rcd
    mov Frame.HomeR8[rsp], r8
    mov Frame.HomeR9[rsp], r9

    alloc_stack 64

    END_PROLOG
    
    ; *do stuff*

    BEGIN_EPILOG

    add rsp, 64

    NESTED_END Foo, _TEXT$00

https://msdn.microsoft.com/en-us/library/tawsa7cb.aspx

Re: How the Windows Subsystem for Linux Redirects Syscalls

#154

Post by niels_olson » Thu, Jun 09, 2016, 2:10 AM UTC

trentnelson wrote: post #131

niels_olson wrote: post #125

Earlier quoted context omitted.

Here's a nice graphical comparison of syscalls between Linux and Windows http://www.visualcomplexity.com/vc/project.cfm?id=392 Are you saying the Windows flow looks like spaghetti only because the software tested software (Apache) wasn't designed for Windows?

Heh, 10 years old, original link doesn't work, image is tiny. And it sounds like they were comparing Linux and Apache to IIS and Windows. It's hard to evaluate this in any way more than "yeah that's a cute spaghetti diagram". If I wanted to drag Linux through the mud visually I'd depict how much time every socket I/O op spends in vfs/fsync stuff. (i.e. you can depict anything to make your point)

That might be a cool diagram to show! I honestly know nothing about kernel programming, just happened to come across that a long time ago and bookmarked it.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#155

Post by 0xcde4c3db » Thu, Jun 09, 2016, 2:21 AM UTC

monocasa wrote: post #149

trentnelson wrote: post #139

Earlier quoted context omitted.

I haven't actually. Although now I'm kind of curious.

It pretty much a complete implementation down to the kernel APIs.

One of the (former?) main kernel developers on ReactOS, Alex Ionescu, is even a co-author on the latest editions of Windows Internals.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#156

Post by wfunction » Thu, Jun 09, 2016, 2:22 AM UTC

xorblurb wrote: post #84

wfunction wrote: post #81

Earlier quoted context omitted.

> Cutler pretended to not like the "everything is a file" approach, but NT does basically the same thing with "everything is a handle". And soon enough, you hit exactly the same conceptual limitations (except not in the same places) that not everything is actually the same, so that cute abstraction leaks soon enough (well, it does in any OS). Explain? Pretty much the only thing you can do with a handle is to release…

You are right, but those points are details. FD under modern Unixes (esp. Linux, but probably others) serves exactly the same purpose (resource management). The FD where read/write can't be used just don't define those (same principle for other syscalls) -- similarly if you try to NtReadFile on an incompatible Handle it will also give you an error back. Both are in a single numbering space per process. NT largely mak…

> You are right, but those points are details.

Uh, no, they are very crucial details. For example, it means the difference between letting root delete /dev/null like any other "file" on Linux, versus an admin not being able to delete \Device\Null on Windows because it isn't a "file". The nonsense Linux lets you do because it treats everything like a "file" is the problem here. It's not a naming issue.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#157

Post by trentnelson » Thu, Jun 09, 2016, 2:23 AM UTC

adamnemecek wrote: post #141

trentnelson wrote: post #98

Earlier quoted context omitted.

Curiosity got the better of me recently when I re-read Russinovich's [NT and VMS - The Rest Of The Story]( http://windowsitpro.com/windows-client/windows-nt-and-vms-re... ), and I bought a copy of [VMS Internals and Data Structures]( http://www.amazon.com/VAX-VMS-Internals-Data-Structures/dp/1... ). Side-by-side, comparing VMS to UNIX, and VMS's approach to a few key areas like I/O, ASTs and tiered interrupt levels a…

Can I ask what else is on your reading list? I ended up buying the VMS Internals book. Also do you have an opinion on BeOS?

I was fascinated by BeOS in the late 90s when I had a lot of enthusiasm (and little clue). All their threading claims just sounded so cool. I was also really into FreeBSD from around 2.2.5 so I got to see how all the SMPng stuff (and kqueue!) evolved, as well as all the different threading models people in UNIX land were trying (1:1, 1:m, m:n).

NT solves it properly. Efficient multithreading support and I/O (especially asynchronous I/O) are just so intrinsically related. Trying to bend UNIX processes and IPC and signals and synchronous I/O into an efficient threading implementation is just trying to fit a square peg in a round hole in my opinion.

As for reading list... I've bought so many old books lately. Here's my "makes the short list" bookshelf: http://imgur.com/DfTUVQx

And the more ridiculous one that I use as a cover page on my resume: http://imgur.com/0u9OZcN

What things in particular are you interested in?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#158

Post by trentnelson » Thu, Jun 09, 2016, 2:27 AM UTC

zxcvcxz wrote: post #127

trentnelson wrote: post #119

Earlier quoted context omitted.

I'm incredibly biased. But that bias has come from assessing the technical details and concluding that NT really is superior, if that's any consolation. PyParallel flogs the Windows versions of things like Go, Node and Tornado because none of those were implemented in a way that allows the NT completion-oriented I/O facilities to be optimally exploited. It's depressing, honestly. In the sense that open source softwar…

So no one has replicated your findings and you're better than everyone else? K. edit: TBH it looks like you're making multiple accounts to comment on your own posts to make the comments that disagree with you appear lower. You and the child above mine had this same conversation 383 days ago: https://news.ycombinator.com/item?id=9584269 This is pathetic. for posterity: https://web.archive.org/web/20160609010955/https:…

Well now I have no idea what you're talking about.

I can barely remember the password to this hacker news account let alone managing multiple identities.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#159

Post by trentnelson » Thu, Jun 09, 2016, 2:31 AM UTC

justinmk wrote: post #147

trentnelson wrote: post #119

Earlier quoted context omitted.

I'm incredibly biased. But that bias has come from assessing the technical details and concluding that NT really is superior, if that's any consolation. PyParallel flogs the Windows versions of things like Go, Node and Tornado because none of those were implemented in a way that allows the NT completion-oriented I/O facilities to be optimally exploited. It's depressing, honestly. In the sense that open source softwar…

> things like Go, Node and Tornado [does not allow] the NT completion-oriented I/O facilities to be optimally exploited. nodejs is built on libuv[1], which uses IOCP on Windows (and epoll, kqueue, etc. on other platforms). What's non-optimal about it? [1] https://github.com/libuv/libuv

"The things that bothers me about all the 'async I/O' libraries out there... is that the implementation -- single-threaded, non-blocking sockets, event loop, I/O multiplex via kqueue/epoll, is well suited to Linux/BSD/OSX, but there's nothing asynchronous about it, it's technically synchronous non-blocking I/O, and it's inherently single-threaded."

https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#160

Post by trentnelson » Thu, Jun 09, 2016, 2:39 AM UTC

bitwize wrote: post #150

zxcvcxz wrote: post #114

Earlier quoted context omitted.

Here's what I don't understand: If IOCP gives us such a great performance boost why don't I see people using it, even on Windows systems? The first thing that comes to mind is that IOCP can likely only maintain high performance under certain edge-cases that aren't pertinent to the real world, second is that the other I/O models are needed not for unix, but for other aspects of the language its self where IOCP is not…

Inertia and the fact that select/epoll/kqueue loops are "good enough".

Bingo.

Not only that but exploiting NT optimally takes a lot of knowledge about a lot of very low-level kernel details, which you sort of need to make a concerted effort to really learn, which is made harder by no official access to (recent) source code.

So I genuinely think there are just fewer programmers out there that specialize in this sort of stuff. There's definitely a correlation between well-above-the-average programmers trending toward open source contribution, but not really the same level of intellectual curiosity about NT/Windows.

One thing I've noticed is that all the people that grok really low level NT kernel details usually end up as reverse engineering experts.

Oh, except for the OSR internals list, that is usually overflowing with clue (both now and historically).