On Sun, Jul 14, 2002 at 10:22:19AM +0530, Dipankar Sarma wrote:
>> Even if you replace timemr_bh() with a tasklet, you still need
>> to take the global_bh_lock to ensure that timers don't race with
>> single-threaded BH processing in drivers. I wrote this patch [included]
>> to get rid of timer_bh in Ingo's smptimers, but it acquires
>> global_bh_lock as well as net_bh_lock, the latter to ensure
>> that some older protocol code that expected serialization of
>> NET_BH and timers work correctly (see deliver_to_old_ones()).
>> They need to be cleaned up too.
>> My patch of course was experimental to see what is needed to
>> get rid of timer_bh. It needs some cleanup itself ;-)
On Thu, Jul 18, 2002 at 01:22:38AM -0700, William Lee Irwin III wrote:
> It turns out those profiling results are total garbage. oprofile
> hit counts during the tbench 1024 run with smptimers-X1 on the 16-way
> 16GB NUMA-Q follow:
Oh yes, bandwidth was increased from 23MB/s to 37MB/s.
And the rundown on .text.lock.dev:
c020249d 43051806 73.9493 .text.lock.dev
c02024f9 10357 0.0240571
c02024fc 121387 0.281956
c02024fe 10282 0.0238829
c0202515 5777619 13.4202
c0202518 31534891 73.2487
c020251a 5596759 13.0001
c020251c 10 2.32278e-05
c0202521 11 2.55506e-05
c0202522 158 0.000367
c0202523 34 7.89746e-05
c0202524 34 7.89746e-05
c0202529 61 0.00014169
c020252a 125 0.000290348
c020252b 36 8.36202e-05
c020252c 42 9.75569e-05
c0202518: f3 90 repz nop
c020251a: 7e f9 jle c0202515 <.text.lock.dev+0x78>
c020251c: e9 83 e1 ff ff jmp c02006a4 <dev_queue_xmit+0x224>
[...]
c0200694: e8 eb 78 f1 ff call c0117f84 <printk>
c0200699: 0f 0b ud2a
c020069b: 7b 00 jnp c020069d <dev_queue_xmit+0x21d>
c020069d: 40 inc %eax
c020069e: 5c pop %esp
c020069f: 29 c0 sub %eax,%eax
c02006a1: 83 c4 08 add $0x8,%esp
c02006a4: f0 fe 0f lock decb (%edi)
c02006a7: 0f 88 68 1e 00 00 js c0202515 <.text.lock.dev+0x78>
c02006ad: 8b 44 24 10 mov 0x10(%esp,1),%eax
c02006b1: 89 86 e8 00 00 00 mov %eax,0xe8(%esi)
c02006b7: 8b 46 24 mov 0x24(%esi),%eax
c02006ba: a8 01 test $0x1,%al
c02006bc: 0f 85 a1 00 00 00 jne c0200763 <dev_queue_xmit+0x2e3>
c02006c2: 83 3d 60 5f 3b c0 00 cmpl $0x0,0xc03b5f60
c02006c9: 74 0a je c02006d5 <dev_queue_xmit+0x255>
c02006cb: 56 push %esi
c02006cc: 55 push %ebp
c02006cd: e8 42 fc ff ff call c0200314 <dev_queue_xmit_nit>
This leads me to believe it's the dev->xmit_lock as that's protects the
critical section in which dev_queue_xmit_nit() is called.
Cheers,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:26 EST