> > There are ways of fixing the writer starvation and allowing recursive
> > read locks, but that is more work (and heavier-weight than desirable).
>
> One such way would be a variant of queued locks, like John Stultz's
>
http://oss.software.ibm.com/developer/opensource/linux/patches/?patch_id=218
> These are usually needed for fairness even with plain spinlocks on NUMA
> boxes in any case (so if your box is NUMA then you will need it anyways)
> They only exist for plain spinlocks yet, but I guess they could be
extended
> to readlocks.
This ES7000 system is not NUMA. All memory is equidistant from all
processors,
with a full non-blocking crossbar interconnect, and the hardware guarantees
fairness under cacheline contention. So the processors aren't being starved
or treated unfairly by the hardware, just by the reader-preference locking
code.
It isn't obvious to me how to extend those queued to reader/writer locks if
you
have to allow recursive readers without incurring the same overhead of
tracking
which processors already have a reader lock.
If you do want to trigger recursive rw_locks, simply change the header file
to
make them normal spinlocks. Then whenever the kernel hangs, see where it
is.
Of course, this approach only finds all of them if you execute every code
path.
Does anyone want to chip in on why we need recursive r/w locks? Or why it
is hard to remove them? It doesn't sound like they are used much.
Kevin
On Tue, Jul 30, 2002 at 12:06:54PM -0500, Van Maren, Kevin wrote:
> It isn't obvious to me how to extend those queued to reader/writer
> locks if you have to allow recursive readers without incurring the
> same overhead of tracking which processors already have a reader lock.
> If you do want to trigger recursive rw_locks, simply change the header
> file to make them normal spinlocks. Then whenever the kernel hangs,
> see where it is. Of course, this approach only finds all of them if
> you execute every code path.
> Does anyone want to chip in on why we need recursive r/w locks? Or why it
> is hard to remove them? It doesn't sound like they are used much.
The tasklist_lock is taken in interrupt context by sigio generation,
and read_locks on it are permitted to be interrupted by other read_locks,
where write_locks of it must mask interrupts locally to prevent deadlock.
I think IA64 performance monitor code does it in interrupt context too.
Older (2.4.x and 2.5.x-early) took the tasklist_lock in interrupt
context to compute the load average by traversing the list of all tasks.
My concern when I changed that was largely timeslice overrun.
Cheers,
Bill