From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f195.google.com ([209.85.216.195]:35362 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752805AbcGYRlg (ORCPT ); Mon, 25 Jul 2016 13:41:36 -0400 Date: Mon, 25 Jul 2016 13:41:32 -0400 From: Tejun Heo To: Christoph Lameter Cc: Waiman Long , Alexander Viro , Jan Kara , Jeff Layton , "J. Bruce Fields" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Andi Kleen , Dave Chinner , Boqun Feng , Scott J Norton , Douglas Hatch Subject: Re: [PATCH v4 0/5] vfs: Use dlock list for SB's s_inodes list Message-ID: <20160725174132.GC19588@mtj.duckdns.org> References: <1469219756-26353-1-git-send-email-Waiman.Long@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, Christoph. On Mon, Jul 25, 2016 at 08:48:25AM -0500, Christoph Lameter wrote: > On Fri, 22 Jul 2016, Waiman Long wrote: > > > - Add a new patch to make the percpu head structure cacheline aligned > > to prevent cacheline contention from disrupting the performance > > of nearby percpu variables. > > It would be better not to use the percpu allocation etc for this. > Given the frequency of off node data access I would say that the data > structure does not qualify as per cpu data. You have per cpu data items > yes but this is not used as per cpu data. I don't get it. What's the harm of using percpu memory here? Other percpu data structures have remote access too. They're to a lower degree but I don't see a clear demarcation line and making addtions per-cpu seems to have significant benefits here. If there's a better way of splitting the list and locking, sure, let's try that but short of that I don't see anything wrong with doing this per-cpu. Thanks. -- tejun