From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28 Date: Fri, 21 Nov 2008 01:05:08 -0800 (PST) Message-ID: <20081121.010508.40225532.davem@davemloft.net> References: <20081121083044.GL16242@elte.hu> <49267694.1030506@cosmosbay.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49267694.1030506-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: Text/Plain; charset="us-ascii" To: dada1-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org Cc: mingo-X9Un+BFzKDI@public.gmane.org, cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, rjw-KKrjLPT3xs0@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, efault-Mmb7MZpHnFY@public.gmane.org, a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org From: Eric Dumazet Date: Fri, 21 Nov 2008 09:51:32 +0100 > Now, I wish sockets and pipes not going through dcache, not tbench affair > of course but real workloads... > > running 8 processes on a 8 way machine doing a > > for (;;) > close(socket(AF_INET, SOCK_STREAM, 0)); > > is slow as hell, we hit so many contended cache lines ... > > ticket spin locks are slower in this case (dcache_lock for example > is taken twice when we allocate a socket(), once in d_alloc(), another one > in d_instantiate()) As you of course know, this used to be a ton worse. At least now these things are unhashed. :) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753289AbYKUJFh (ORCPT ); Fri, 21 Nov 2008 04:05:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752840AbYKUJFL (ORCPT ); Fri, 21 Nov 2008 04:05:11 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:55118 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752262AbYKUJFJ (ORCPT ); Fri, 21 Nov 2008 04:05:09 -0500 Date: Fri, 21 Nov 2008 01:05:08 -0800 (PST) Message-Id: <20081121.010508.40225532.davem@davemloft.net> To: dada1@cosmosbay.com Cc: mingo@elte.hu, cl@linux-foundation.org, rjw@sisk.pl, linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org, efault@gmx.de, a.p.zijlstra@chello.nl Subject: Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28 From: David Miller In-Reply-To: <49267694.1030506@cosmosbay.com> References: <20081121083044.GL16242@elte.hu> <49267694.1030506@cosmosbay.com> X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet Date: Fri, 21 Nov 2008 09:51:32 +0100 > Now, I wish sockets and pipes not going through dcache, not tbench affair > of course but real workloads... > > running 8 processes on a 8 way machine doing a > > for (;;) > close(socket(AF_INET, SOCK_STREAM, 0)); > > is slow as hell, we hit so many contended cache lines ... > > ticket spin locks are slower in this case (dcache_lock for example > is taken twice when we allocate a socket(), once in d_alloc(), another one > in d_instantiate()) As you of course know, this used to be a ton worse. At least now these things are unhashed. :)