Re: Advice on a multithreaded netisr patch?





--- On Wed, 4/8/09, Robert Watson <rwatson@xxxxxxxxxxx> wrote:

From: Robert Watson <rwatson@xxxxxxxxxxx>
Subject: Re: Advice on a multithreaded netisr patch?
To: "Barney Cordoba" <barney_cordoba@xxxxxxxxx>
Cc: "Ivan Voras" <ivoras@xxxxxxxxxxx>, freebsd-net@xxxxxxxxxxx
Date: Wednesday, April 8, 2009, 9:16 AM
On Wed, 8 Apr 2009, Barney Cordoba wrote:

Is there any work being done on lighter weight locks
for queues? It seems ridiculous to avoid using queues
because of lock contention when the locks are only
protecting a couple lines of code.

My reading is that there are two, closely related, things
going on: the first is lock contention, and the second is
cache line contention. We have a primitive in 8.x
(don't think it's been MFC'd yet) for a lockless
atomic buffer primitive for use in drivers and other parts
of the stack. However, that addresses only lock contention,
not line contention, which at a high PPS will be an issue as
well. Only by moving to independent data structures (i.e.,
on independent cache lines) can we reduce line contention.

Robert N M Watson
Computer Laboratory
University of Cambridge

Are mutexes smart enough to know to yield to higher priority threads
that are waiting immediately? Such as

mtx_unlock()
{
do_unlock_stuff();
if (higher_pri_waiting)
sched_yield()
}

Also is there a way from the structure or flags to determing is some
other thread is waiting on the lock, such as?

mtx_unlock(&mtx);
if (mtx.someone_is_waiting)
sched_yield();

or better yet

if (higher_priority_is_waiting)
sched_yield()

I don't quite have a handle on how the turnstile works, but it seems
that there is a lot of time waiting for very short-lived locks. If
the tasks are on different cpus, what is the granularity of the wait
time for a lock that is cleared almost immediately after trying it?

Also, is the waiting only extended when the threads are running on the
same cpu?

Barney



_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH RFC] smt nice introduces significant lock contention
    ... kernel/sched.c:dependent_sleeperwas responsible for most of the lock ... we are hitting on lock contention, but by the large amount of code it ... dependent_sleeper by only doing trylock on the smt sibling runqueues. ... * Try to lock all the siblings of a cpu that is already locked. ...
    (Linux-Kernel)
  • [ckpatch][2/29] sched-revise_smt_nice_locking
    ... Initial report and lock contention fix from Chris Mason: ... convert wake_sleeping_dependent to use trylock ... * Called with interrupt disabled and this_rq's runqueue locked. ...
    (Linux-Kernel)
  • RE: [PATCH RFC] smt nice introduces significant lock contention
    ... Recent benchmarks showed some performance regressions between 2.6.16 and ... kernel/sched.c:dependent_sleeperwas responsible for most of the lock ... this also sort of echo a recent discovery on one of our benchmarks ... we are hitting on lock contention, but by the large amount of code it ...
    (Linux-Kernel)
  • RE: [PATCH RFC] smt nice introduces significant lock contention
    ... Recent benchmarks showed some performance regressions between 2.6.16 and ... We tracked down one of the regressions to lock contention in schedule ... this also sort of echo a recent discovery on one of our benchmarks ...
    (Linux-Kernel)
  • Re: IISState log help
    ... Thread is waiting for a lock to be released. ... Stack unwind information not available. ... the question then is why is the lock contention so high? ...
    (microsoft.public.inetserver.iis)
Quantcast