Ivan> I'm thinking about the issues of the use of spinlocks in the
Ivan> Cyclades async driver. However, I have a very minimal idea on
Ivan> how spinlocks work. Before you ask: yes, I've read the
Ivan> Documentation/spinlocks.txt and the include/asm/spinlock.h
Ivan> files.
Ivan> The biggest issue is that we're talking about multiport serial
Ivan> cards, which means several devices under one card, one IRQ, and
Ivan> sometimes one chip (the CD1400 controls 4 ports
Ivan> simultaneously). Thus, the access control should be done in
Ivan> three levels:
Ivan> - one spinlock for regions that are accessed inside the
Ivan> interrupt handler; - one for regions that are specific to each
Ivan> port; - one for regions that are specific to each chip;
Hi
I would be very careful with that, adding more than one spin lock to
the driver means you will have to be _very_ careful not to get
yourself into deadlock situations.
In fact what is interesting here is to avoid holding the locks as much
as possible, since locks means busy waiting. If the hardware is sane
(I don't know anything about the Cyclades) you can actually very often
go a long way by putting some thought into looking at what really
needs to be locked. Sometimes a few atomic types can make wonders. I
have just been hacking the AceNIC Gigabit driver to not have any lock
contention in the interrupt and transmit handlers.
For a card with four ports on, you may want a lock that protects it
from accessing the same registers at the same time if more CPUs are
trying to transmit in parallel. For the interrupt handler you will
need to take the lock if it messes with the same registers or other
data structures.
What you may want to do is to just use one lock in the beginning and
then do some profiling to see how much lock contention you actually
see. You can do this by fiddling a bit with spin_trylock().
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/