From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bl2nam02on0137.outbound.protection.outlook.com ([104.47.38.137]:12997 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753280AbcGUBgi (ORCPT ); Wed, 20 Jul 2016 21:36:38 -0400 Message-ID: <57902719.8060903@hpe.com> Date: Wed, 20 Jul 2016 21:36:25 -0400 From: Waiman Long MIME-Version: 1.0 To: Christoph Lameter CC: Tejun Heo , Alexander Viro , Jan Kara , Jeff Layton , "J. Bruce Fields" , , , Ingo Molnar , Peter Zijlstra , Andi Kleen , Dave Chinner , Boqun Feng , Scott J Norton , Douglas Hatch Subject: Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists References: <1468604383-40362-1-git-send-email-Waiman.Long@hpe.com> <1468604383-40362-2-git-send-email-Waiman.Long@hpe.com> <20160718233803.GN3078@mtj.duckdns.org> <578E7497.30602@hpe.com> <578FF813.3040901@hpe.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/20/2016 08:48 PM, Christoph Lameter wrote: > On Wed, 20 Jul 2016, Waiman Long wrote: > >> Christoph, are you OK with Tejun's request to revert the name back to >> percpu_list? Or do you still think the current name is better? > The percpu structure contains a spinlock and may be remotely accessed? You > are aware that other percpu variables that share the same cacheline will > be negatively impacted by accesses from other processors? The spinlock can be remotely accessed during deletion as well as the iteration of all the percpu lists. Iteration of all the percpu data is not a new thing as it may also be done in percpu_counter when calling percpu_counter_sum(). Yes, remote access can have a negative performance impact on the access of other percpu data that happen to reside in the same cacheline. > The role of percpu areas are to have memory areas where the code can > expect that cachelines are exclusively there for that processor. > > How frequent are the remote accesses? If this is rare then ok. I can't say how often that will happen for the dlock list. If the thread that create the inodes does not migrate to other CPU, the deletion of the inode should also happens in the same CPU. One way to reduce the performance impact is to make the percpu head structure cacheline aligned at the expense of some wasted space. I could add an additional parameter to alloc_dlock_list_head() to force cacheline alignment if the caller wish to do so. What do think about that? Cheers, Longman