[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081117195757.GA12020@elte.hu>
Date: Mon, 17 Nov 2008 20:57:57 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Eric Dumazet <dada1@...mosbay.com>,
David Miller <davem@...emloft.net>, rjw@...k.pl,
linux-kernel@...r.kernel.org, kernel-testers@...r.kernel.org,
cl@...ux-foundation.org, efault@....de, a.p.zijlstra@...llo.nl,
Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [Bug #11308] tbench regression on each kernel release from
2.6.22 -> 2.6.28
> [ I'll post per function analysis as i complete them, as a reply to
> this mail. ]
[ i'll do a separate mail for every function analyzed, the discussion
spreads better that way. ]
> 100.000000 total
> ................
> 7.253355 copy_user_generic_string
This is the Well-known pattern of user-copy overhead, which centers
around this single REP MOVS instruction:
nr-of-hits
.........
ffffffff80341eea: 42 83 e2 07 and $0x7,%edx
ffffffff80341eed: 677398 f3 48 a5 rep movsq %ds:(%rsi),%es:(%rdi)
ffffffff80341ef0: 3642 89 d1 mov %edx,%ecx
ffffffff80341ef2: 16260 f3 a4 rep movsb %ds:(%rsi),%es:(%rdi)
ffffffff80341ef4: 6554 31 c0 xor %eax,%eax
ffffffff80341ef6: 1958 c3 retq
ffffffff80341ef7: 0 90 nop
ffffffff80341ef8: 0 90 nop
That's to be expected - tbench shuffles 3.5 GB of effective data
to/from sockets. That's 7.5 GB due to double-copy. So for every 64
bytes of data transferred we spend 1.4 CPU cycles in this specific
function - that is OK-ish.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists