Remove the deferred flushing implementation in the Intel
VT-d driver and use the one from the common iova code
instead.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The shift qi_flush_dev_iotlb() is done on an int, which
limits the mask to 32 bits. Make the mask 64 bits wide so
that more than 4GB of address range can be flushed at once.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add a timer to flush entries from the Flush-Queues every
10ms. This makes sure that no stale TLB entries remain for
too long after an IOVA has been unmapped.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The lock is taken from the same CPU most of the time. But
having it allows to flush the queue also from another CPU if
necessary.
This will be used by a timer to regularily flush any pending
IOVAs from the Flush-Queues.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
There are two counters:
* fq_flush_start_cnt - Increased when a TLB flush
is started.
* fq_flush_finish_cnt - Increased when a TLB flush
is finished.
The fq_flush_start_cnt is assigned to every Flush-Queue
entry on its creation. When freeing entries from the
Flush-Queue, the value in the entry is compared to the
fq_flush_finish_cnt. The entry can only be freed when its
value is less than the value of fq_flush_finish_cnt.
The reason for these counters it to take advantage of IOMMU
TLB flushes that happened on other CPUs. These already
flushed the TLB for Flush-Queue entries on other CPUs so
that they can already be freed without flushing the TLB
again.
This makes it less likely that the Flush-Queue is full and
saves IOMMU TLB flushes.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add a function to add entries to the Flush-Queue ring
buffer. If the buffer is full, call the flush-callback and
free the entries.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This patch adds the basic data-structures to implement
flush-queues in the generic IOVA code. It also adds the
initialization and destroy routines for these data
structures.
The initialization routine is designed so that the use of
this feature is optional for the users of IOVA code.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Sudeep reports that the logic got slightly broken when a PCI iommu-map
entry targets an IOMMU marked as disabled in DT, since of_pci_map_rid()
succeeds in following a phandle, and of_iommu_xlate() doesn't return an
error value, but we miss checking whether ops was actually non-NULL.
Whilst this could be solved with a point fix in of_pci_iommu_init(), it
suggests that all the juggling of ERR_PTR values through the ops pointer
is proving rather too complicated for its own good, so let's instead
simplify the whole flow (with a side-effect of eliminating the cause of
the bug).
The fact that we now rely on iommu_fwspec means that we no longer need
to pass around an iommu_ops pointer at all - we can simply propagate a
regular int return value until we know whether we have a viable IOMMU,
then retrieve the ops from the fwspec if and when we actually need them.
This makes everything a bit more uniform and certainly easier to follow.
Fixes: d87beb7492 ("iommu/of: Handle PCI aliases properly")
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add support for the iommu_device_register interface to make
the s390 hardware iommus visible to the iommu core and in
sysfs.
Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
It's ok to disable iommu early in normal kernel or in kdump kernel when
amd_iommu=off is specified. While we should not disable it in kdump kernel
when on-flight dma is still on-going.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
When iommu is pre_enabled in kdump kernel, if a device is set up with
guest translations (DTE.GV=1), then don't copy GCR3 table root pointer
but move the device over to an empty guest-cr3 table and handle the
faults in the PPR log (which answer them with INVALID). After all these
PPR faults are recoverable for the device and we should not allow the
device to change old-kernels data when we don't have to.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
AMD pointed out it's unsafe to update the device-table while iommu
is enabled. It turns out that device-table pointer update is split
up into two 32bit writes in the IOMMU hardware. So updating it while
the IOMMU is enabled could have some nasty side effects.
The safe way to work around this is to always allocate the device-table
below 4G, including the old device-table in normal kernel and the
device-table used for copying the content of the old device-table in kdump
kernel. Meanwhile we need check if the address of old device-table is
above 4G because it might has been touched accidentally in corrupted
1st kernel.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Implement call-back is_attach_deferred and use it to defer the
domain attach from iommu driver init to device driver init when
iommu is pre-enabled in kdump kernel.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Firstly split the dev table entry copy into address translation part
and irq remapping part. Because these two parts could be enabled
independently.
Secondly do sanity check for address translation and irq remap of old
dev table entry separately.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Here several things need be done:
- If iommu is pre-enabled in a normal kernel, just disable it and print
warning.
- If any one of IOMMUs is not pre-enabled in kdump kernel, just continue
as it does in normal kernel.
- If failed to copy dev table of old kernel, continue to proceed as
it does in normal kernel.
- Only if all IOMMUs are pre-enabled and copy dev table is done well, free
the dev table allocated in early_amd_iommu_init() and make amd_iommu_dev_table
point to the copied one.
- Disable and Re-enable event/cmd buffer, install the copied DTE table
to reg, and detect and enable guest vapic.
- Flush all caches
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add function copy_dev_tables to copy the old DEV table entries of the panicked
kernel to the new allocated device table. Since all iommus share the same device
table the copy only need be done one time. Here add a new global old_dev_tbl_cpy
to point to the newly allocated device table which the content of old device
table will be copied to. Besides, we also need to:
- Check whether all IOMMUs actually use the same device table with the same size
- Verify that the size of the old device table is the expected size.
- Reserve the old domain id occupied in 1st kernel to avoid touching the old
io-page tables. Then on-flight DMA can continue looking it up.
And also define MACRO DEV_DOMID_MASK to replace magic number 0xffffULL, it can be
reused in copy_dev_tables().
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
In AMD-Vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining them respectively can make code more read-able. Do it now.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This reverts commit 54bd635704.
We still need the IO_PAGE_FAULT message to warn error after the
issue of on-flight dma in kdump kernel is fixed.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Move single iommu enabling codes into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Sunxi_defconfig is refreshed and various power supply and ADC drivers
of the AXP PMICs have been enabled.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEE2nN1m/hhnkhOWjtHOJpUIZwPJDAFAlmH12AOHHdlbnNAY3Np
ZS5vcmcACgkQOJpUIZwPJDCVdA/7Bhw+Zuhr2rA3N13SQYeYUNfm2Uu53zToNrUc
WSsWwhc2XfkPDNHRkcYx0s5n6/Ouiw7W32c+uCt9HhfbXA02r/Vz7WrWRXXY83e4
2zGNXsVVLN9AU/fYXomzcfyZI0qxLzoTXPF4U5YYI1QazvSs0L8p1SNKpu15PUbH
p5HMao3cYR8EVXyKxALq5GpIxv0Sd7C7UXA/D7op7oIZOkQaHBhXuQb5mgub1x8t
Vbrd/KmI+nmNqm+1/gJ3jMd9KYfRE5DDY0WZH8z62GZ8oUE89VmyoFQzX53qPHAY
NHJ7LPR2Fo7z6k2JDKERhOFb+3BHmjySDfwEzfovFPbMgG+Yrca0EDVWBK0X3Rc3
sZtmgTbywX1Im3VlZkWdtLSqaMf6igWNQQ5y9dID2rwQx/+ys8S9ldL1Afhgh3n7
kdYHKCt4rju/U/kykr9BZnZyZsmRPO3qoXKjV2yWkgClxxtAcYiqtRSSswqSNNCU
BCh3takfi2hZRSgY4bz6KirkJmRMDJ5HkU7Noz1nGHEoXOsjyTnvX9r4RBf5OlSo
iwhgWCnOecHdO6pV8qcwePrH9HXKOAHMquzMKBv65NJLDtvNXCsharFMk7isQUFa
OqyPANOCGsJIiPnukli44wBD6Nrk59esckeQzYEbdg3LwYYPpfeShQaBim4SCgxu
sPwrqYo=
=nZWf
-----END PGP SIGNATURE-----
Merge tag 'sunxi-defconfig-for-4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into next/defconfig
Pull "Allwinner defconfig changes for 4.14" from Chen-Yu Tsai:
Sunxi_defconfig is refreshed and various power supply and ADC drivers
of the AXP PMICs have been enabled.
* tag 'sunxi-defconfig-for-4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm: sunxi: Add AXP20X_ADC
arm: sunxi: Add additional power supplies
arm: sunxi: refresh the defconfig
- Enable Kirin PCIe host, hi6421v530 mfd and regulator,
syscon reboot mode, serdev bus, OP-TEE and K3 DMA support
for hikey and hikey960
- Enable pcie based sas controller support for hip08 SoC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZkc7VAAoJEAvIV27ZiWZcud0QAK6Pi/oB8qLy0xUCdkcIYHhI
XJD+PKMkZNdgWccW9bTqxVjb7iecEBA3IO1KqKvAOlQ9psjDZYuY7pJlXxhlNgmP
ulYvZpMQeKosUB/cT4ZjcTNQ/OB1Z+GNmP/HbWC6vGFyZH8ZDbXpd195+q4KKi+c
fs53ULbu5bJ22i6WYMId7fufRDXFwZoJHZWQaDUVYsmOOeFKHoS0m+NeEwZHXB2k
ruoJKF117t3xScp2GCfBIJH28cfRcmirNv6UKconX7IpuQqhZqBiYi3xYrM3bfsd
xqH9iY+SX6xb1J/gvP4zyPVrcMAB24eJI/1jSf9ipjpPBFA1iAECsVgnZ0xR8SUI
U62JGV+w/qOq/5A5En9izUY+TSmxqTsmBp5/sj7uQqM8MBIkUvD98i9PAC5fdNBh
rqKGl2qwa+VJLdfrI7U1fNJiwWCJrFWGytCTWEF0A+8ZKVVbIBvcl8pkz76kaTb6
PfQzSUSuL6sqZXXzQqVfJ89llu31C5kkIyUdaMd0JgqVnZ9NKUaOhkVlTIOKsbTl
Nrf9fta2g6xXjVjU7NEeacrtN4+kUKzARfzzAWNi5AumKuL/dhjP98QO5LF/87SC
UbVWeb2fftV5g8Yv9tFVA0vWRRJKGnBzRxwJw7ext7fKOesVnnQntwX5bl55KRqa
3lC8l/KnXp95x3z5ZrSF
=AEey
-----END PGP SIGNATURE-----
Merge tag 'hisi-defconfig-for-4.14' of git://github.com/hisilicon/linux-hisi into next/arm64
Pull "ARM64: hisilicon: defconfig updates for 4.14" from Wei Xu:
- Enable Kirin PCIe host, hi6421v530 mfd and regulator,
syscon reboot mode, serdev bus, OP-TEE and K3 DMA support
for hikey and hikey960
- Enable pcie based sas controller support for hip08 SoC
* tag 'hisi-defconfig-for-4.14' of git://github.com/hisilicon/linux-hisi:
arm64: defconfig: enable DMA driver for hi3660
arm64: defconfig: enable OP-TEE
arm64: defconfig: enable support for serial port connected device
arm64: defconfig: enable CONFIG_SYSCON_REBOOT_MODE
arm64: defconfig: enable support hi6421v530 PMIC
arm64: defconfig: enable Kirin PCIe
arm64: defconfig: enable SCSI_HISI_SAS_PCI
Add the arm64 crypto drivers that have been added over the past
couple of kernel releases to its defconfig as modules.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enabling nop-xceiv PHY driver in the defconfig, needed for USB support
on A8K SoC based board.
Enabling fine-grained task level IRQ time accounting for ARMv8 as it was
already done for x86
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlmNg88ACgkQCwYYjhRyO9UgWwCeLnJikdCOF4YoN3fxw6NxNivN
cAwAn0z2IYh42j7UoBwxINih2byehBL8
=ZHwt
-----END PGP SIGNATURE-----
Merge tag 'mvebu-arm64-4.14-1' of git://git.infradead.org/linux-mvebu into next/arm64
Pull "mvebu arm64 for 4.14 (part 1)" from Gregory CLEMENT:
Enabling nop-xceiv PHY driver in the defconfig, needed for USB support
on A8K SoC based board.
Enabling fine-grained task level IRQ time accounting for ARMv8 as it was
already done for x86
* tag 'mvebu-arm64-4.14-1' of git://git.infradead.org/linux-mvebu:
arm64: defconfig: enable fine-grained task level IRQ time accounting
arm64: defconfig: enable nop-xceiv PHY driver
Add zstd compression and decompression support to BtrFS. zstd at its
fastest level compresses almost as well as zlib, while offering much
faster compression and decompression, approaching lzo speeds.
I benchmarked btrfs with zstd compression against no compression, lzo
compression, and zlib compression. I benchmarked two scenarios. Copying
a set of files to btrfs, and then reading the files. Copying a tarball
to btrfs, extracting it to btrfs, and then reading the extracted files.
After every operation, I call `sync` and include the sync time.
Between every pair of operations I unmount and remount the filesystem
to avoid caching. The benchmark files can be found in the upstream
zstd source repository under
`contrib/linux-kernel/{btrfs-benchmark.sh,btrfs-extract-benchmark.sh}`
[1] [2].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD.
The first compression benchmark is copying 10 copies of the unzipped
Silesia corpus [3] into a BtrFS filesystem mounted with
`-o compress-force=Method`. The decompression benchmark times how long
it takes to `tar` all 10 copies into `/dev/null`. The compression ratio is
measured by comparing the output of `df` and `du`. See the benchmark file
[1] for details. I benchmarked multiple zstd compression levels, although
the patch uses zstd level 1.
| Method | Ratio | Compression MB/s | Decompression speed |
|---------|-------|------------------|---------------------|
| None | 0.99 | 504 | 686 |
| lzo | 1.66 | 398 | 442 |
| zlib | 2.58 | 65 | 241 |
| zstd 1 | 2.57 | 260 | 383 |
| zstd 3 | 2.71 | 174 | 408 |
| zstd 6 | 2.87 | 70 | 398 |
| zstd 9 | 2.92 | 43 | 406 |
| zstd 12 | 2.93 | 21 | 408 |
| zstd 15 | 3.01 | 11 | 354 |
The next benchmark first copies `linux-4.11.6.tar` [4] to btrfs. Then it
measures the compression ratio, extracts the tar, and deletes the tar.
Then it measures the compression ratio again, and `tar`s the extracted
files into `/dev/null`. See the benchmark file [2] for details.
| Method | Tar Ratio | Extract Ratio | Copy (s) | Extract (s)| Read (s) |
|--------|-----------|---------------|----------|------------|----------|
| None | 0.97 | 0.78 | 0.981 | 5.501 | 8.807 |
| lzo | 2.06 | 1.38 | 1.631 | 8.458 | 8.585 |
| zlib | 3.40 | 1.86 | 7.750 | 21.544 | 11.744 |
| zstd 1 | 3.57 | 1.85 | 2.579 | 11.479 | 9.389 |
[1] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/btrfs-benchmark.sh
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/btrfs-extract-benchmark.sh
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.11.6.tar.xz
zstd source repository: https://github.com/facebook/zstd
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Add zstd compression and decompression kernel modules.
zstd offers a wide varity of compression speed and quality trade-offs.
It can compress at speeds approaching lz4, and quality approaching lzma.
zstd decompressions at speeds more than twice as fast as zlib, and
decompression speed remains roughly the same across all compression levels.
The code was ported from the upstream zstd source repository. The
`linux/zstd.h` header was modified to match linux kernel style.
The cross-platform and allocation code was stripped out. Instead zstd
requires the caller to pass a preallocated workspace. The source files
were clang-formatted [1] to match the Linux Kernel style as much as
possible. Otherwise, the code was unmodified. We would like to avoid
as much further manual modification to the source code as possible, so it
will be easier to keep the kernel zstd up to date.
I benchmarked zstd compression as a special character device. I ran zstd
and zlib compression at several levels, as well as performing no
compression, which measure the time spent copying the data to kernel space.
Data is passed to the compresser 4096 B at a time. The benchmark file is
located in the upstream zstd source repository under
`contrib/linux-kernel/zstd_compress_test.c` [2].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using `silesia.tar` [3], which is
211,988,480 B large. Run the following commands for the benchmark:
sudo modprobe zstd_compress_test
sudo mknod zstd_compress_test c 245 0
sudo cp silesia.tar zstd_compress_test
The time is reported by the time of the userland `cp`.
The MB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Adjusted MB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
The memory reported is the amount of memory the compressor requests.
| Method | Size (B) | Time (s) | Ratio | MB/s | Adj MB/s | Mem (MB) |
|----------|----------|----------|-------|---------|----------|----------|
| none | 11988480 | 0.100 | 1 | 2119.88 | - | - |
| zstd -1 | 73645762 | 1.044 | 2.878 | 203.05 | 224.56 | 1.23 |
| zstd -3 | 66988878 | 1.761 | 3.165 | 120.38 | 127.63 | 2.47 |
| zstd -5 | 65001259 | 2.563 | 3.261 | 82.71 | 86.07 | 2.86 |
| zstd -10 | 60165346 | 13.242 | 3.523 | 16.01 | 16.13 | 13.22 |
| zstd -15 | 58009756 | 47.601 | 3.654 | 4.45 | 4.46 | 21.61 |
| zstd -19 | 54014593 | 102.835 | 3.925 | 2.06 | 2.06 | 60.15 |
| zlib -1 | 77260026 | 2.895 | 2.744 | 73.23 | 75.85 | 0.27 |
| zlib -3 | 72972206 | 4.116 | 2.905 | 51.50 | 52.79 | 0.27 |
| zlib -6 | 68190360 | 9.633 | 3.109 | 22.01 | 22.24 | 0.27 |
| zlib -9 | 67613382 | 22.554 | 3.135 | 9.40 | 9.44 | 0.27 |
I benchmarked zstd decompression using the same method on the same machine.
The benchmark file is located in the upstream zstd repo under
`contrib/linux-kernel/zstd_decompress_test.c` [4]. The memory reported is
the amount of memory required to decompress data compressed with the given
compression level. If you know the maximum size of your input, you can
reduce the memory usage of decompression irrespective of the compression
level.
| Method | Time (s) | MB/s | Adjusted MB/s | Memory (MB) |
|----------|----------|---------|---------------|-------------|
| none | 0.025 | 8479.54 | - | - |
| zstd -1 | 0.358 | 592.15 | 636.60 | 0.84 |
| zstd -3 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -5 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -10 | 0.374 | 566.81 | 607.42 | 2.51 |
| zstd -15 | 0.379 | 559.34 | 598.84 | 4.61 |
| zstd -19 | 0.412 | 514.54 | 547.77 | 8.80 |
| zlib -1 | 0.940 | 225.52 | 231.68 | 0.04 |
| zlib -3 | 0.883 | 240.08 | 247.07 | 0.04 |
| zlib -6 | 0.844 | 251.17 | 258.84 | 0.04 |
| zlib -9 | 0.837 | 253.27 | 287.64 | 0.04 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/UserlandTest.cpp` [5] by mocking the kernel
functions. Fuzz tested using libfuzzer [6] with the fuzz harnesses under
`contrib/linux-kernel/test/{RoundTripCrash.c,DecompressCrash.c}` [7] [8]
with ASAN, UBSAN, and MSAN. Additionaly, it was tested while testing the
BtrFS and SquashFS patches coming next.
[1] https://clang.llvm.org/docs/ClangFormat.html
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_compress_test.c
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_decompress_test.c
[5] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/UserlandTest.cpp
[6] http://llvm.org/docs/LibFuzzer.html
[7] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/RoundTripCrash.c
[8] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/DecompressCrash.c
zstd source repository: https://github.com/facebook/zstd
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an
extremely fast non-cryptographic hash algorithm for checksumming.
The zstd compression and decompression modules added in the next patch
require xxhash. I extracted it out from zstd since it is useful on its
own. I copied the code from the upstream XXHash source repository and
translated it into kernel style. I ran benchmarks and tests in the kernel
and tests in userland.
I benchmarked xxhash as a special character device. I ran in four modes,
no-op, xxh32, xxh64, and crc32. The no-op mode simply copies the data to
kernel space and ignores it. The xxh32, xxh64, and crc32 modes compute
hashes on the copied data. I also ran it with four different buffer sizes.
The benchmark file is located in the upstream zstd source repository under
`contrib/linux-kernel/xxhash_test.c` [1].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using the file `filesystem.squashfs`
from `ubuntu-16.10-desktop-amd64.iso`, which is 1,536,217,088 B large.
Run the following commands for the benchmark:
modprobe xxhash_test
mknod xxhash_test c 245 0
time cp filesystem.squashfs xxhash_test
The time is reported by the time of the userland `cp`.
The GB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Normalized GB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
| Buffer Size (B) | Hash | Time (s) | GB/s | Adjusted GB/s |
|-----------------|-------|----------|------|---------------|
| 1024 | none | 0.408 | 3.77 | - |
| 1024 | xxh32 | 0.649 | 2.37 | 6.37 |
| 1024 | xxh64 | 0.542 | 2.83 | 11.46 |
| 1024 | crc32 | 1.290 | 1.19 | 1.74 |
| 4096 | none | 0.380 | 4.04 | - |
| 4096 | xxh32 | 0.645 | 2.38 | 5.79 |
| 4096 | xxh64 | 0.500 | 3.07 | 12.80 |
| 4096 | crc32 | 1.168 | 1.32 | 1.95 |
| 8192 | none | 0.351 | 4.38 | - |
| 8192 | xxh32 | 0.614 | 2.50 | 5.84 |
| 8192 | xxh64 | 0.464 | 3.31 | 13.60 |
| 8192 | crc32 | 1.163 | 1.32 | 1.89 |
| 16384 | none | 0.346 | 4.43 | - |
| 16384 | xxh32 | 0.590 | 2.60 | 6.30 |
| 16384 | xxh64 | 0.466 | 3.30 | 12.80 |
| 16384 | crc32 | 1.183 | 1.30 | 1.84 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/XXHashUserlandTest.cpp` [2] by mocking the
kernel functions. A line in each branch of every function in `xxhash.c`
was commented out to ensure that the test-suite fails. Additionally
tested while testing zstd and with SMHasher [3].
[1] https://phabricator.intern.facebook.com/P57526246
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/XXHashUserlandTest.cpp
[3] https://github.com/aappleby/smhasher
zstd source repository: https://github.com/facebook/zstd
XXHash source repository: https://github.com/cyan4973/xxhash
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
* compile ak4613 and renesas sound as modules
This is intended to reduce the size of a kernel image compiled
using the defconfig. This is timely as it brings the kernel image
back below the size that can be booted in my environment, a limit
it crept over in v4.13-rc1.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZfziqAAoJENfPZGlqN0++yFIQAIHtAfEpIKff7ELoEGgNOzs2
8F89igteIxumVy5to1XNVvWksoYSakWzjrOMV3dzj+llYxsjg5d7Mfc+oadNsfWy
40dFQw84QHzobqJ0I2NbhV8+1M0K4DslfzphFjB6KQK/WfDa9iw4G/GeoahX/SHP
smNd/etE0YULwnO0rujzhC3dcGiusU7u80D8yc/VlDLgAGalZP5HYP0QZ3cwBf0P
ONwjkBO6rU8e+HRYLbQkAKR9UWKXZHruM1KUrPhxkDk/+KNaEOfTDQWSuIUFokxl
bU+LV750nT8hIXXLBlX4WtkaT5uaHJoUfHXEpQnEKjXaPC4u2zVqhofZxcaIFW5R
0c/MhRmC4e8BnPQLljZqU5180qCKKXWAejYX3dRT9yUvTnHzZU8LVSn1QY4+Pvrf
CixTdXjLQOcn9G8WpInZ63xCT1j9aVY28KOVSLtUtVl/08LbEuD66PxNje45MEpp
yvi8khhvaWzpY2wPK7I3hmFIO55IYMNBfqmnNlGnuBkxNn1j1ZXSl+4P8Q41Q2GD
jXqu8cK9mJlyxwf0OSUQJQNY5c+uzcX2rKtDbf9Lkb9OnUBv8gqtvDVdaHKJzpTg
gRpvVs3mEEuT8sntECONBqsTfOEziZofwOgOSPiXoQqRHaY0NnUVW7TlBHQY4xAA
zLpnjzlpgkw6sJNU3t0h
=PAs6
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm64-defconfig-for-v4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/arm64
Pull "Renesas ARM64 Based SoC Defconfig Updates for v4.14" from Simon Horman:
* compile ak4613 and renesas sound as modules
This is intended to reduce the size of a kernel image compiled
using the defconfig. This is timely as it brings the kernel image
back below the size that can be booted in my environment, a limit
it crept over in v4.13-rc1.
* tag 'renesas-arm64-defconfig-for-v4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: defconfig: compile ak4613 and renesas sound as modules
commit cee22a1505 ("workqueues: Introduce new flag WQ_POWER_EFFICIENT
for power oriented workqueues") introduced the concept of power
efficient workqueues (4 years back), but it was never enabled in
upstream kernel configs.
Power efficient workqueues are simply marked as "unbound," so that jobs
queued to them can run on any CPU in the system. It leaves the target
CPU selection to the scheduler, which is the best place for such
decision making. This improves power efficiency for workqueues which are
otherwise pinned to a CPU.
Enable it for ARM64 platforms as ARM platforms were the main target for
the introduction of power efficient workqueues.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add the (previously omitted) Ether/PHY pin data to the SK-RZG1E board's
device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add the (previously omitted) SCIF2 pin data to the SK-RZG1E board's
device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Define the generic R8A7745 part of the PFC device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
* Enable DMA for Renesas serial ports
Geert Uytterhoeven says, "DMA for (H)SCIF(A|B) serial ports on Renesas
R-Car Gen2 and RZ/G1 SoCs is considered stable, hence enable it by
default.".
* Enable Ethernet AVB
For the iWave RZ/G1M Q7 SOM
* Replace DRM_RCAR_HDMI by generic bridge options
* Replace SND_SOC_RSRC_CARD by SND_SIMPLE_SCU_CARD
* Replace USB_XHCI_RCAR by USB_XHCI_PLATFORM
* Enable missing PCIE_RCAR dependency
Defconfig updates for various Kconfig updates covering
renamed Kconfig symbols, now missing dependancies and so on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZfz/nAAoJENfPZGlqN0++9LgQAKIOBAenrdTDAqnGVAbRwGyE
5jK4G5SXlMUp6Te8uC1CZWPGY544KRadth++R7V92LjTN3nsKrBczohN6/I1vbxJ
x0Fkna6cSXdOLmLb/Wlauvim8OxLd/WJ8ITZBQjlayc7QfaqAffasDov0P2IxyIs
VtDxmwN+DUrXDWl/XShAwDzw5Ey0J/I+CsOQaRmdJCaZl5zGO1SAKI6wt3c45dP3
HeDRVHg4I0YyetDmQw3+ILE7lzKmWAeuZ9nY8X4zD4VSS3cVppT+oPTMi/Etx1Dn
BgsOGHl2WtprKImn0ZWKi8jIMjP+jIaRqlwe71c2fY8qLuAdib5R9yq2BbOOIxz+
tfeNsMKG9MR6iJ7SaG+vftVCyMr7rrKcSlptVkkmiI1pDa41HHW70QqkeQsXWYSH
fzfb7BYHxZVgRbHIryIyUT7hiEDQyAIGyb4JwUCIilNfEJ3jTfAaEwML0aSp35V5
5r+vO4pFUTXeaY/OxhSlSp9YrZfuhW805b2YHddmQNxFJBYpK8rdc3Hn+TkmPYkB
LNtJerC6Qrg6vjVteRyDWljVK0EyP98K/Xb4yRLg3C05LrOMdm0ALa323+Tgf+Fk
gk2amBiTJo3w274ckB6856dYrLv+QnvXz/sZt7tTrIqS4QDj9VIVYWKcYIhNvnQt
zJC7EFwfum7yZ4LbEKkl
=qKJg
-----END PGP SIGNATURE-----
Merge tag 'renesas-defconfig-for-v4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/defconfig
Pull "Renesas ARM Based SoC Defconfig Updates for v4.14" from Simon Horman:
* Enable DMA for Renesas serial ports
Geert Uytterhoeven says, "DMA for (H)SCIF(A|B) serial ports on Renesas
R-Car Gen2 and RZ/G1 SoCs is considered stable, hence enable it by
default.".
* Enable Ethernet AVB
For the iWave RZ/G1M Q7 SOM
* Replace DRM_RCAR_HDMI by generic bridge options
* Replace SND_SOC_RSRC_CARD by SND_SIMPLE_SCU_CARD
* Replace USB_XHCI_RCAR by USB_XHCI_PLATFORM
* Enable missing PCIE_RCAR dependency
Defconfig updates for various Kconfig updates covering
renamed Kconfig symbols, now missing dependancies and so on.
* tag 'renesas-defconfig-for-v4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports
ARM: multi_v7_defconfig: Replace DRM_RCAR_HDMI by generic bridge options
ARM: multi_v7_defconfig: Replace SND_SOC_RSRC_CARD by SND_SIMPLE_SCU_CARD
ARM: shmobile: defconfig: Refresh
ARM: shmobile: defconfig: Enable DMA for serial ports
ARM: shmobile: defconfig: Replace DRM_RCAR_HDMI by generic bridge options
ARM: shmobile: defconfig: Replace SND_SOC_RSRC_CARD by SND_SIMPLE_SCU_CARD
ARM: shmobile: defconfig: Replace USB_XHCI_RCAR by USB_XHCI_PLATFORM
ARM: shmobile: defconfig: Enable missing PCIE_RCAR dependency
ARM: shmobile: defconfig: Enable Ethernet AVB
If a request is on the commit list, but is locked, we will currently skip
it, which can lead to livelocking when the commit count doesn't reduce
to zero.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Now that we no longer hold the inode->i_lock when manipulating the
commit lists, it is safe to call pnfs_put_lseg() again.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Switch from using the inode->i_lock for this to avoid contention with
other metadata manipulation.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
The commit lists can get very large, so using the inode->i_lock can
end up affecting general metadata performance.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Split out the 2 cases so that we can treat the locking differently.
The issue is that the locking in the pageswapcache cache is highly
linked to the commit list locking.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Hide the locking from nfs_lock_and_join_requests() so that we can
separate out the requirements for swapcache pages.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Fix up the test in nfs_page_group_covers_page(). The simplest implementation
is to check that we have a set of intersecting or contiguous subrequests
that connect page offset 0 to nfs_page_length(req->wb_page).
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
nfs_page_group_lock() is now always called with the 'nonblock'
parameter set to 'false'.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
At this point, we only expect ever to potentially see PG_REMOVE and
PG_TEARDOWN being set on the subrequests.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Since nfs_page_group_destroy() does not take any locks on the requests
to be freed, we need to ensure that we don't inadvertently free the
request in nfs_destroy_unlinked_subrequests() while the last reference
is being released elsewhere.
Do this by:
1) Taking a reference to the request unless it is already being freed
2) Checking (under the page group lock) if PG_TEARDOWN is already set before
freeing an unreferenced request in nfs_destroy_unlinked_subrequests()
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
When locking the entire group in order to remove subrequests,
the locks are always taken in order, and with the page group
lock being taken after the page head is locked. The intention
is that:
1) The lock on the group head guarantees that requests may not
be removed from the group (although new entries could be appended
if we're not holding the group lock).
2) It is safe to drop and retake the page group lock while iterating
through the list, in particular when waiting for a subrequest lock.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
