From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755464Ab3JABFL (ORCPT ); Mon, 30 Sep 2013 21:05:11 -0400 Received: from mail-pd0-f170.google.com ([209.85.192.170]:63871 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755388Ab3JABFG (ORCPT ); Mon, 30 Sep 2013 21:05:06 -0400 Message-ID: <1380589503.5326.13.camel@edumazet-glaptop.roam.corp.google.com> Subject: spinlock contention of files->file_lock From: Eric Dumazet To: Linus Torvalds , Al Viro Cc: Ingo Molnar , Peter Zijlstra , Waiman Long , Benjamin Herrenschmidt , "Chandramouleeswaran, Aswin" , Linux Kernel Mailing List , linux-fsdevel Date: Mon, 30 Sep 2013 18:05:03 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Speaking of spinlock contention, the files->file_lock is a good example. Multi threaded programs hit this spinlock three times per fd : alloc_fd() / fd_install() / close() I think fd_install() could be done without this spinlock. we want to protect fd_install() from a concurrent resize of the fd table. We could either : - Add a spinlock used for resize, and fd_install(). A bit suboptimal but easy to code and review. - Add a seqcount, and cmpxchg() to synchronize fd_install() with the potential resizer. (Might need additional RCU locking)