Is there some method of lock profiling on plan9? For example when I do
work on freebsd and say remove a giant lock from the keyboard subsystem; I run
the lock profiler before and after the change to see how long the system was
sitting at the in kernel locks.
I am doing my thesis (undergrad) on these kind of topics and am interested
in seeing how I may be of use.
=jt
------Original Message------
From: erik quanstrom
Sender: 9fans-boun...@9fans.net
To: 9fans@9fans.net
ReplyTo: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] "Blocks" in C
Sent: Sep 18, 2009 07:41
> it isn't really a `big kernel lock' in the linux sense.
you're right, technically it is a very different problem.
the effects seem similar. the lock is just in the block allocator
rather than the syscall interface. if you're doing a lot of i/o
in a standard kernel, there's a lot of block allocation.
> with error checking. an alternative allocator that uses quickfit on top of
> a variant of the simple allocator in kernighan and ritchie is
> roughly 30 times faster on some malloc-thrashing tests (i'm just remembering
> that
> from tests i did last year, so i might have the number wrong, but it's
> substantial).
i see the same thing. with the allocator in a specific packet-pushing
test, i see 185000 packets/s, with a block pool i see ~450000 packets/s.
all the packets are the same size.
would you be willing to share your allocator? this may help a number
of cases i'm currently fighting. 10gbe and 2×10gbe + quad processors
have a way of putting a sharp point on an otherwise dull problem.
i also wonder if an ilock is really the right protection
mechanism on machines with 8 or 16 logical processors
for malloc.
the reason i mention this is that it turns out that the lock
on block pools can be hot enough that splitting the lock
per controller can have a big positive effect. i need to set
up a faster target, but i've seen significant jumps in bandwidth
for 2 82563 controllers when using 2 pools instead of one
even on a fairly bored machine.
sorry for the lack of real numbers.
- erik
=jt
