remove the former.
All other EGA/VGA methods were already shared, with VGA-only features
mostly not used and no decisions in inner loops to optimize fof VGA,
but this method was split up because it is the only important one and
using VGA methods if possible is about twice as fast. The speed is
mostly not from splitting to reduce branches but from doing half as
many bus accesses, so make this easier to maintain by not splitting.
There is now 1 extra branch in an inner loop where it costs less than
1% of the bus access overhead on Haswell even if the compiler schedules
it poorly.
Before this change it was impossible to set number of PKCS#5v2 iterations,
required to set passphrase, if it has two keys and never had any passphrase.
Due to present metadata format limitations there are still cases when number
of iterations can not be changed, but now it works in cases when it can.
PR: 218512
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D10338
vga planar method (for testing that was supposed to be local that the
former still works). The ega method works on vga but is about twice
as slow. The vga method doesn't work on ega.
Optimize the main vga planar method a little. For changing the
background color (which was otherwise optimized better than most
things), don't switch the write mode from 3 to 0 just to select
the pixel mask of 0xff obscurely by writing 0. Just write 0xff
directly.
-(SYNCOOKIE_LIFETIME + 1) instead of INT64_MIN, since it is
good enough and works when time_t is int32 or int64.
This fixes the issue reported by cy@ on i386.
Reported by: cy
MFC after: 1 week
Sponsored by: Netflix, Inc.
The default uid/gid for NFSv4 are set by the nfsuserd(8) daemon.
However, they were 0 until the nfsuserd(8) was run. Since it is
possible to use NFSv4 without running the nfsuserd(8) daemon, set them
to nobody/nogroup initially.
Without this patch, the values would be set by the nfsuserd(8) daemon
and left changed even if the nfsuserd(8) daemon was killed. Also, the default
values of 0 meant that setting a group to "wheel" would fail even when
done by root and this patch fixes this issue.
MFC after: 2 weeks
7490 real checksum errors are silenced when zinject is on
illumos/illumos-gate@6cedfc397d6cedfc397dhttps://www.illumos.org/issues/7490
When zinject is on, error codes from zfs_checksum_error() can be overwritten
due to an incorrect and overly-complex if condition.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Pavel Zakharov <pavel.zakharov@delphix.com>
7448 ZFS doesn't notice when disk vdevs have no write cache
illumos/illumos-gate@295438ba32295438ba32https://www.illumos.org/issues/7448
I built a SmartOS image with all the NVMe commits including 7372
(support NVMe volatile write cache) and repeated my dd testing:
> #!/bin/bash
> for i in `seq 1 1000`; do
> dd if=/dev/zero of=file00 bs=1M count=102400 oflag=sync &
> dd if=/dev/zero of=file01 bs=1M count=102400 oflag=sync &
> wait
> rm file00 file01
> done
>
Previously each dd command took ~145 seconds to finish, now it takes
~400 seconds.
Eventually I figured out it is 7372 that causes unnecessary
nvme_bd_sync() executions which wasted CPU cycles.
If a NVMe device doesn't support a write cache, the nvme_bd_sync function will
return ENOTSUP to indicate this to upper layers.
It seems this returned value is ignored by ZFS, and as such this bug is not
really specific to NVMe. In vdev_disk_io_start() ZFS sends the flush to the
disk driver (blkdev) with a callback to vdev_disk_ioctl_done(). As nvme filled
in the bd_sync_cache function pointer, blkdev will not return ENOTSUP, as the
nvme driver in general does support cache flush. Instead it will issue an
asynchronous flush to nvme and immediately return 0, and hence ZFS will not set
vdev_nowritecache here. The nvme driver will at some point process the cache
flush command, and if there is no write cache on the device it will return
ENOTSUP, which will be delivered to the vdev_disk_ioctl_done() callback. This
function will not check the error code and not set nowritecache.
The right place to check the error code from the cache flush is in
zio_vdev_io_assess(). This would catch both cases, synchronous and asynchronous
cache flushes. This would also be independent of the implementation detail that
some drivers can return ENOTSUP immediately.
Reviewed by: Dan Fields <dan.fields@nexenta.com>
Reviewed by: Alek Pinchuk <alek.pinchuk@nexenta.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>
Author: Hans Rosenfeld <hans.rosenfeld@nexenta.com>
Obtained from: Illumos
The FreeBSD NFSv4 server did not set the attribute bit for TimeAccess in
the reply to an Open with exclusive_create, as required by the RFCs.
(This is required since the FreeBSD NFS server stores the create_verifier
in the va_atime attribute.)
As such, the Linux NFSv4 client did not set the TimeAccess (atime) in
the Setattr done in an RPC after the one with the Open/exclusive_create.
This patch fixes the server to set the TimeAccess bit in the reply.
I believe that storing the create_verifier in an extended attribute for
file systems that support extended attributes might be a good idea,
but I will wait for a discussion of this on the freebsd-fs@ email list
before considering committing a patch to do this.
Reported by: jim@ks.uiuc.edu
Suggested by: dfr
MFC after: 2 weeks
7430 Backfill metadnode more intelligently
illumos/illumos-gate@af346df588af346df588https://www.illumos.org/issues/7430
Description and patch from brought over from the following ZoL commit: https://
github.com/zfsonlinux/zfs/commit/68cbd56e182ab949f58d004778d463aeb3f595c6
Only attempt to backfill lower metadnode object numbers if at least
4096 objects have been freed since the last rescan, and at most once
per transaction group. This avoids a pathology in dmu_object_alloc()
that caused O(N^2) behavior for create-heavy workloads and
substantially improves object creation rates. As summarized by
@mahrens in #4636:
"Normally, the object allocator simply checks to see if the next
object is available. The slow calls happened when dmu_object_alloc()
checks to see if it can backfill lower object numbers. This happens
every time we move on to a new L1 indirect block (i.e. every 32 *
128 = 4096 objects). When re-checking lower object numbers, we use
the on-disk fill count (blkptr_t:blk_fill) to quickly skip over
indirect blocks that don?t have enough free dnodes (defined as an L2
with at least 393,216 of 524,288 dnodes free). Therefore, we may
find that a block of dnodes has a low (or zero) fill count, and yet
we can?t allocate any of its dnodes, because they've been allocated
in memory but not yet written to disk. In this case we have to hold
each of the dnodes and then notice that it has been allocated in
memory.
The end result is that allocating N objects in the same TXG can
require CPU usage proportional to N^2."
Add a tunable dmu_rescan_dnode_threshold to define the number of
objects that must be freed before a rescan is performed. Don't bother
to export this as a module option because testing doesn't show a
compelling reason to change it. The vast majority of the performance
gain comes from limit the rescan to at most once per TXG.
Reviewed by: Alek Pinchuk <alek@nexenta.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Gordon Ross <gordon.w.ross@gmail.com>
Author: Ned Bass <bass6@llnl.gov>
Obtained from: Illumos
overflows, syncookies are used.
This patch restricts the usage of syncookies in this case: accept
syncookies only if there was an overflow of the syncache recently.
This mitigates a problem reported in PR217637, where is syncookie was
accepted without any recent drops.
Thanks to glebius@ for suggesting an improvement.
PR: 217637
Reviewed by: gnn, glebius
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D10272
a pointer to the main ega drawing method which is misoptimized be in
a different function than the main vga planar mode drawing method.
Vga initialization handles everything with no extra code except for
selecting the different function.
corresponding to the gaps between characters. This fixes distortion
of the cursor due to expanding it across the gaps.
Again for character width 9, when the cursor characters are not in the
graphics range (0xb0-0xdf), the gaps were always there (filled in the
background color for the previous char). They still look strange, but
don't cause distortion. When the cursor characters are in the graphics
range, the gaps are filled by repeating the previous line. This gives
distortion with cilia. Removing vertical lines reduces the distortion
to vertical cilia.
Move the default for the cursor characters out of the graphics range.
With character width 9, this gives gaps instead of distortion and
other problems. With character width 8, it just fixes a smaller set
of other problems. Some distortion and other problems can be recovered
using vidcontrol -M. Presumably the default was to fill the gaps
intentionally, but it is much better to leave gaps. The gaps can even
be considered as a feature for text processing -- they give sub-pointers
to character boundaries. The other problems are: (1) with character
width 9, characters near the cursor are moved into the graphics range
and thus distorted if any of their 8th bits is set; (2) conflicts with
national characters in the graphics range.
The default range for the graphics cursor characters is now 8-11. This
doesn't conflict with anything, since the glyphs for the characters in
this range are unreachable.
Use the 10x16 mouse cursor in text mode too (if the font size is >= 14).
When the character width is 9, removal of 1 or 2 vertical lines makes
10x16 cursor no wider than the 9x13 one usually was. We could even
handle cursors 1 pixel wider in 2 character cells and gaps without
more clipping than given by the gaps (the worst case is 1 pixel in the
left cell, 1 removed in the middle gap, 8 in the right cell and 1
removed in the right gap. The pixel in the right gap is removed so
it doesn't matter if it is in the font).
When the character width is 8, we now clip the 10-wide cursor by 1
pixel in the worst case. This clipping is usually invisible since it
is of the border and and the border usually merges with the background
so is invisible. There should be an option to use reverse video to
highlight the border and its tip instead of the interior (graphics
mode can do better using separate colors). This needs the 9x13 cursor
again.
Ideas from: ache (especially about the bad default character range)
Note that KVA mapping of the framebuffer already uses write-combining
mode, so the change, besides improving speed of user mode writes, also
satisfies requirement of the IA32 architecture of using consistent
caching modes for multiple mappings of the same page.
Reported and tested by: bde
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
not consider a "disabled" cpu as a CPU we have to ignore, and we should use
them if they provide a "enable-method".
While I'm there, support "ok" as well as "okay", while ePAPR only accepts
"okay", linux accepts "ok" too so we can expect it to be used.
Reviewed by: andrew (partially)
9 wide.
I only need this to improve the mouse cursor, but it has always been
needed to select and/or adjust fonts.
This is complicated because there are no standard parameter tables
giving this bit of information directly, and the device register bit
giving the information can't be trusted even if it is read from the
hardware. Use a heuristic to guess if the device register can be
trusted. (The device register is normally read from the BIOS mode
table, but on my system where the device register is wrong, the mode
table doesn't match the hardware and is not used; the device registers
are used in this case.)
When forwarding pf tracks the size of the largest fragment in a fragmented
packet, and refragments based on this size.
It failed to ensure that this size was a multiple of 8 (as is required for all
but the last fragment), so it could end up generating incorrect fragments.
For example, if we received an 8 byte and 12 byte fragment pf would emit a first
fragment with 12 bytes of payload and the final fragment would claim to be at
offset 8 (not 12).
We now assert that the fragment size is a multiple of 8 in ip6_fragment(), so
other users won't make the same mistake.
Reported by: Antonios Atlasis <aatlasis at secfu net>
MFC after: 3 days
mode.
Use the general DRAWPIXEL() macro with its bigger case statement
(twice) instead of our big case statement (once). DRAWPIXEL() is more
complicated since it is not missing support for depth 24 or
complications for colors in depth 16 (we currently hard-code black and
white so the complications for colors are not needed). DRAWPIXEL()
also does the bpp calculation in the inner loop. Compilers optimize
DRAWPIXEL() well enough, and the main text drawing method always
depended on this. In direct mode, mouse cursor drawing is now similar
to normal text drawing except it draws in 2 hard-coded colors instead
of 1 variable color.
This also fixes a nested hard-coding of colors. DRAWPIXEL() uses the
palette in all cases, but the direct code didn't use the palette for
its hard-coded black. This only had an effect in depth 8, since
changing the palette is not supported in other depths.
direct mode renderer. I thought that reads were not much slower than
writes, so that the method only tripled the time for the whole function,
but I recently measured that video memory reads can be up to 53 times
slower than writes in tighter loops than here. Loop overheap here
reduces the multiplier to only 16-20 on Haswell.
Start cleaning up and fixing larger bugs in this function. Only replace
the 22-line removal loop by a 3-line one for now, since adjusting the
old loop would have required many palette calculations which are better
done in the DRAW_PIXEL() macro. This also fixes missing support for
depth 24, but only for removal.
Removal is currently sloppy at the right bottom corner. It sometimes
leaks border color into the text window. This is soon cleaned up by the
caller. The planar renderer has complications to clip at the corner.
using a driver-supplied sbuf for printing device discovery
announcements. This helps ensure that messages to the console
will be properly serialized (through sbuf_putbuf) and not be
truncated and interleaved with other messages. The
infrastructure mirrors the existing xpt_announce_periph()
entry point and is opt-in for now. No content or formatting
changes are visible to the operator other than the new coherency.
While here, eliminate the stack usage of the temporary
announcement buffer in some of the drivers. It's moved to the
softc for now, but future work will eliminate it entirely by
making the code flow more linear. Future work will also address
locking so that the sbufs can be dynamically sized.
The scsi_da, scs_cd, scsi_ses, and ata_da drivers are converted
at this point, other drivers can be converted at a later date.
A tunable+sysctl, kern.cam.announce_nosbuf, exists for testing
purposes but will be removed later.
TODO:
Eliminate all of the code duplication and temporary buffers. The
old printf-based methods will be retired, and xpt_announce_periph()
will just be a wrapper that uses a dynamically sized sbuf. This
requires that the register and deregister paths be made malloc-safe,
which they aren't currently.
Sponsored by: Netflix
of our tweaked modes based on it. In practice, this means limiting the
tweaked modes to at most 80x50 based on 80x25, so there are no 90-column,
80x30 or 80x60 modes.
This happens when the the initial mode is is not in the parameter
table. We always detected this case, but assumed that the (necessarily
nonstandard) parameters of the initial mode could be tweaked just as
blindly as the probably-standard parameters of initial modes in the
table.
On 1 laptop system with near-VGA where the initial mode is nonstandard,
this is because the hardware apparently doesn't support 9-bit mode,
but otherwise has standard timing. The initial mode has 8-bit mode
CRTC horizontal parameters similar to those in syscons' 90-column modes
and in EGA modes. Tweaking these values for the 90-column modes has
little effect except to print the extra 10 columns off the screen.
Tweaking from 80x25 to 80x30 requires changing from 400 scan lines to
480. This can probably be made to work, but syscons blindly applies
values based on standard timing. This gives blank output. Tweaking
from 80x25 to 80x50 doesn't change the CRTC timing and works.
kit, CK, in the LinuxKPI.
When threads are pinned to a CPU core or when there is only one CPU,
it can happen that a higher priority thread can call the CK
synchronize function while a lower priority thread holds the read
lock. Because the CK's synchronize is a simple wait loop this can lead
to a deadlock situation. To solve this problem use the recently
introduced CK's wait callback function.
When detecting a CK blocking condition figure out the lowest priority
among the blockers and update the calling thread's priority and
yield. If another CPU core is holding the read lock, pin the thread to
the blocked CPU core and update the priority. The calling threads
priority and CPU bindings are restored before return.
If a thread holding a CK read lock is detected to be sleeping, pause()
will be used instead of yield().
MFC after: 1 week
Sponsored by: Mellanox Technologies
CPUs when allocating a LinuxKPI workqueue. This also ensures that the
created taskqueue always have a non-zero number of worker threads.
MFC after: 1 week
Sponsored by: Mellanox Technologies
According to Warner, multiple TRIM BIOs are collapsed into a single CCB with
NULL bp. It is invalid to biotrack() NULL, and results in a fault. So,
don't do that.
Reported by: asomers@
Sponsored by: Dell EMC Isilon
As the uboot disk interface is using common/disk.c API, we also
should use disk_ioctl() call, this will give us chance to read partition
sizes and have feature parity with UEFI and BIOS implementations.
This does also fix arm boot issue on some systems, reported/tested by Ian,
thanks.
Reported by: ian
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D10421
The work to make it possible to avoid bcache via using F_NORA modifier did
miss the fact that not all loader platforms are using the bcache, and so
it is possible the modifier is not cleared, as bcache strategy function is
not used.
For fix, we make sure the checks are dont with masked flag.
This patch does fix boot for platforms which do not use bcache.
Reported by: emaste
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10422
