a1d6eba4 | 29-Apr-2019 |
Peeter Must <karu.pruun@gmail.com> |
kernel/ums: Use evdev's private lock for ums
* evdev can use either an internal or an external lock (the parent driver's lock) to protect its private data in evdev_dev. For ums evdev uses the um
kernel/ums: Use evdev's private lock for ums
* evdev can use either an internal or an external lock (the parent driver's lock) to protect its private data in evdev_dev. For ums evdev uses the ums (external) lock. However, sometimes this leads to a panic when the usb mouse is detached. This is because the ums may have cleaned up its structures, including the lock, while the evdev is still busy freeing its resources. If this happens, evdev will panic since it cannot use the lock.
* The remedy is to make evdev use its private lock instead of ums's lock. This is similar to how evdev and ukbd operate.
* A similar situation may occur for other drivers that we will need to link to evdev.
* This change will make our ums/evdev deviate from FreeBSD.
show more ...
|
2efb75f3 | 04-Oct-2018 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Refactor tty_token, fix SMP performance issues
* Remove most uses of tty_token in favor of per-tty tp->t_token. This is particularly important for removing bottlenecks related to PTYs,
kernel - Refactor tty_token, fix SMP performance issues
* Remove most uses of tty_token in favor of per-tty tp->t_token. This is particularly important for removing bottlenecks related to PTYs, which are used all over the place. tty_token remains in a few places managing overall registration and global list manipulation.
* tty structures are now required to be persistent. Implement a sepearate ttyinit() function. Continue to allow ttyregister() and ttyunregister() calls, but these no longer presume destruction of the structure.
* Refactor ttymalloc() to take a **tty pointer and interlock allocations. Allocations are intended to be one-time. ttymalloc() only requires the tty_token for initial allocations.
* Remove all critical section use that was combined with tty_token and tp->t_token. Leave only the tokens. The critical sections were hold-overs going all the way back to pre-SMP days.
* syscons now gets its own token, vga_token. The ISA VGA code and the framebuffer code also now use this token instead of tty_token.
* The keyboard subsystem now uses kbd_token instead of tty_token.
* A few remaining serial-like devices (snp, nmdm) also get their own tokens, as well as use the now required tp->t_token.
* Remove use of tty_token in the session management code. This fixes a niggling performance path since sessions almost universally go hand-in-hand with fork/exec/exit sequences. Instead we use the already-existing per-hash session token.
show more ...
|
50a1f598 | 02-Oct-2018 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Remove duplicate TRIM, only trim with the 'trim' mount opt
* ffs_blkfree_cg() was improperly issuing a synchronous VOP_FREEBLKS() on the underlying device. This issues a BUF_CMD_FREEBL
kernel - Remove duplicate TRIM, only trim with the 'trim' mount opt
* ffs_blkfree_cg() was improperly issuing a synchronous VOP_FREEBLKS() on the underlying device. This issues a BUF_CMD_FREEBLKS stategy op to the underlying device, which is executed unconditionally. This basically runs an unconditional TRIM whether the 'trim' mount flag is specified or not.
Remove the VOP_FREEBLKS() call.
* For softupdates operation, ffs_blkfree() handles the 'trim' mount flag by issuing a BUF_CMD_FREEBLKS and sequencing the call to ffs_blkfree_cg() when it completes.
When 'trim' was enabled, *two* TRIM operations were being executed on the underlying device, and prior to our fix, if 'trim' was not enabled, *one* TRIM operation would still be executed instead of zero.
* In many situations... possibly even most situations, trim operations seriously reduce performance due to being serialized by AHCI or by the target device. It is not as useful as people often think it should be on normal filesystems.
* The removal of the unconditional TRIM significantly improves UFS performance, meaning primarily installkernel's since DragonFly doesn't use UFS for its main filesystem by default any more.
* The 'trim' mount option for UFS will still work as advertised when coupled with softupdates.
show more ...
|