Re: [Lse-tech] local_irq_disable() and highly-contended locks

[george a. <ge...@mv...>]

Martin J. Bligh wrote:
>>>You need to backport some of the tasklist_lock-abuse-prevention work
>>>in 2.5. The one that comes to the top of my mind is proc_read_super()
>>>that walked the entire tasklist to count the number of tasks.
>>
>>The tasklist_lock contention problems I'm seeing for ["modified"] AIM7
>>are the write_lock_irq(&tasklist_lock) in do_fork(), exit_notify(), and
>>release_task().  The underlying root of the problem isn't the
>>write-lock, per se, but the fact that the write-lock is being starved by
>>all the read-lockers (not all of whom are searching the entire task
>>list, BTW).  AIM7 is particularly nasty in this way because of the
>>"signal_test" subtest that uses a flurry of kill() signals and keeps
>>kill_something_info/kill_proc_info busy holding the tasklist_lock.  It
>>will be interesting to see how much of the contention is improved in
>>2.5.  You won't see this level of contention until you get well above
>>8p.
> 
> 
> Could you modify the rwlock implementation to be fair in queuing readers
> and writers, rather than reader-favouring? (solving the contention is
> better still ;-))
> 
I can think of some cases where favouring the writer is the better 
thing (the xtime lock comes to mind).
-g
> M.
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Lse-tech mailing list
> Lse...@li...
> https://lists.sourceforge.net/lists/listinfo/lse-tech
> 
> 

-- 
George Anzinger   ge...@mv...
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml