[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <490AE792.60200@cosmosbay.com>
Date: Fri, 31 Oct 2008 12:10:10 +0100
From: Eric Dumazet <dada1@...mosbay.com>
To: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC: David Miller <davem@...emloft.net>, shemminger@...tta.com,
zbr@...emap.net, rjw@...k.pl, mingo@...e.hu,
s0mbre@...rvice.net.ru, a.p.zijlstra@...llo.nl,
LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>, efault@....de,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [tbench regression fixes]: digging out smelly deadmen.
Ilpo Järvinen a écrit :
> On Fri, 31 Oct 2008, Eric Dumazet wrote:
>
>> David Miller a écrit :
>> > From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
>> > Date: Fri, 31 Oct 2008 11:40:16 +0200 (EET)
>> > > > Let me remind that it is just a single process, so no ping-pong
>> & other
>> > > lock related cache effects should play any significant role here,
>> no? (I'm
>> > > no expert though :-)).
>> > > Not locks or ping-pongs perhaps, I guess. So it just sends and
>> > receives over a socket, implementing both ends of the communication
>> > in the same process?
>> > > If hash chain conflicts do happen for those 2 sockets, just
>> traversing
>> > the chain 2 entries deep could show up.
>>
>> tbench is very sensible to cache line ping-pongs (on SMP machines of
>> course)
>
> ...Sorry to disappoint you but we were discussion there on my AIM9
> tcp_test results :-).
>
Well, before you added AIM9 on this topic, we were focusing on tbench :)
Sorry to disappoint you :)
--
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