
Unmapped I/O improves userland direct disk performance by 35% ~ 135% - antonios
https://svnweb.freebsd.org/base?view=revision&revision=303474
======
pritambaral
From the title, I thought Microsoft had sponsored an improvement in generic
FreeBSD.

From the revision, it seems the improvement is in a Hyper-V storage driver.

~~~
jlgaddis
Indeed, Microsoft has done quite a bit of work towards increasing the
performance of FreeBSD running on Azure / HyperV.

------
exelius
I mean, this only makes sense -- OSes are no longer a core product in the
server world; they're just a part of the application stack. The hypervisor /
orchestrator is the critical part, and that's Hyper-V in the Microsoft world.

Also, this patch doesn't strike me as monumental. Really, it strikes me as one
of the first things you would do when configuring a disk driver for a VM
(mapped I/O is unnecessary overhead for most VM configurations as the
hypervisor and/or SAN remaps it anyway). Has Microsoft not supported FreeBSD
well under HyperV in the past?

~~~
pjmlp
Yeah, the cloud is finally catching up with the mainframes.

~~~
nickpsecurity
They'll have caught up enough when they have I/O coprocessors as general as
Channel I/O. Are there any server standards close to that? And CPU's with the
needed I/O accelerators?

~~~
pixl97
Why would we want specialized processors when a modern CPU core is filled with
dozens of CPU cores? And no, I'm not trying to be snarky, but Channel IO
sounds like something from the days when CPU was rare and expensive but
doesn't make sense in an architecture where lots of cores exist and IOPS and
network are generally a bigger issue. What am I missing?

~~~
twic
Last time I checked, a z-series IO processor was a normal processor that just
want licenced to run application code. Same as how their COBOL processors are
the same as their Java processors, despite being more expensive.

~~~
snaky
AFAIK microcode is the big part of zCPU, that allows reconfigure the way how
zCPU works internally, despite the fact on precise hardware level it's still
the same zCPU.

------
sitkack
I don't understand mapped vs unmapped io in terms of Hyper-V. Does that mean
that io from a user process goes directly to a paravirtualized io device and
bypasses the freebsd kernel?

~~~
nkurz
I had the same question, or maybe even a more basic one: what do they mean by
"unmapped I/O", and is there a different term for this concept in Linux? Does
it perhaps relate to O_DIRECT? To sendfile() and splice()? This paper is the
closest to an answer that I've found:
[http://www.cs.technion.ac.il/~dan/papers/cim-
asplos-2016.pdf](http://www.cs.technion.ac.il/~dan/papers/cim-asplos-2016.pdf)

I think the point is that, currently, BSD (at least with Hyper-V) defaults to
a "mapped" zero-copy approach: when a read is requested, the user space buffer
is mapped to a DMA accessible address, the device DMA's the data directly into
the buffer, and then the DMA address is unmapped.

Unfortunately, the IOMMU operations to make this happen are not free, and have
side-effects like a TLB flush. For small transfers, it's cheaper to let the
DMA write to a persistent kernel buffer, and then have the kernel copy it to
user-space. I think this traditional non-zero-copy approach is what they are
referring to as "unmapped".

But I'm guessing. It would be kind if someone fluent in BSD could explain it
correctly.

------
mrfusion
Can anyone eli5?

~~~
Analemma_
FreeBSD running on Hyper-V (Microsoft's virtualization layer) was slow; now
it's faster thanks to code Microsoft contributed (EDIT: or simply sponsored,
it's not clear).

------
ajamesm
I see now that the patch was sponsored by Microsoft, but for a moment I
thought that this was a new kind of HN text ad.

~~~
kerneis
For those wondering what is going on, the original submission title started
with "sponsored by Microsoft". It has since been edited.

~~~
mikeash
Thank you! I got here after the title change and was terribly confused.

------
honkhonkpants
The style of this diff is bewildering. What's with the gratuitous reformatting
of the whitespace? Makes it difficult for the reader to pick out the
meaningful difference.

~~~
hinkley
Diff tools that can ignore white space changes make code reviews a lot easier.

~~~
tedunangst
Or one can separate white space diffs from functional diffs and reduce the
dependency on particular tooling choices. This often works a lot better
because style diffs often reflow lines that -w doesn't handle.

~~~
hinkley
You can when you don't work on a team with feature branches, but everybody who
failed to understand CI seems to think its a wonderful way to work. And it
turns out there are a lot of them.

