On Wed, Sep 22, 2021 at 03:36:57PM -0400, Waiman Long wrote:I won't call it a hack. I consider it a better documentation what the real intention is.
Currently there are about 12 instances in the kernel where an up_read()And TTY is a high performance issue, that requires hacks like this?
is immediately followed by a down_write() of the same lock. For example,
drivers/tty/n_tty.c: up_read(&tty->termios_rwsem);
drivers/tty/n_tty.c- down_write(&tty->termios_rwsem);
Yes, the best case saving is just just an atomic op.
Since we have already provided a downgrade_write() function, we may asYuck...
well provide an upgrade_read() function to make the code easier to read
and the intention clearer.
If the current task is the only reader, the upgrade can be done by a
single atomic operation. If not, the upgrade will have to be done by a
separate up_read() call followed by a down_write(). In the former case,
the handoff bit is not considered and the waiter will have to wait a
bit longer to acquire the lock.
The new upgrade_read() function returns a value of 0 for safe upgrade
where rwsem protected data won't change. Otherwise a value of 1 is
returned to indicate unsafe upgrade where rwsem protected data may
change during the upgrade process.
Is there any workload where this is a massive win? I'm thinking that
either the lock is contended and you get the unsafe option which is the
same as today, or the lock isn't contended and you would've gotten
fast-paths and you barely safe anything anyway.
Also, -ENODATA