Messages in this thread | | | Subject | Re: Spinlocks: the saga | From | Jes Sorensen <> | Date | 01 Jul 1999 10:17:08 +0200 |
| |
>>>>> "Ivan" == Linux Lists <lists@cyclades.com> writes:
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/
| |