From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f194.google.com ([209.85.220.194]:55240 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751646AbdJ0A5N (ORCPT ); Thu, 26 Oct 2017 20:57:13 -0400 Date: Fri, 27 Oct 2017 08:58:34 +0800 From: Boqun Feng To: Waiman Long Cc: Alexander Viro , Jan Kara , Jeff Layton , "J. Bruce Fields" , Tejun Heo , Christoph Lameter , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Andi Kleen , Dave Chinner , Davidlohr Bueso Subject: Re: [PATCH v7 0/6] vfs: Use dlock list for SB's s_inodes list Message-ID: <20171027005753.GA22994@tardis> References: <1507229008-20569-1-git-send-email-longman@redhat.com> <0c570c02-262e-a62a-9ba6-b1b451e53604@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <0c570c02-262e-a62a-9ba6-b1b451e53604@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 26, 2017 at 02:28:55PM -0400, Waiman Long wrote: > On 10/05/2017 02:43 PM, Waiman Long wrote: > > > > This is a follow up of the following patchset: > > > > [PATCH v7 0/4] vfs: Use per-cpu list for SB's s_inodes list > > https://lkml.org/lkml/2016/4/12/1009 > > > > This patchset provides new APIs for a set of distributed locked lists > > (one/CPU core) to minimize lock and cacheline contention. Insertion > > and deletion to the list will be cheap and relatively contention free. > > Lookup, on the other hand, may be a bit more costly as there are > > multiple lists to iterate. This is not really a problem for the > > replacement of superblock's inode list by dlock list included in > > the patchset as lookup isn't needed. > > > > For use cases that need to do lookup, the dlock list can also be > > treated as a set of hashed lists that scales with the number of CPU > > cores in the system. > > > > Both patches 5 and 6 are added to support other use cases like epoll > > nested callbacks, for example, which could use the dlock-list to > > reduce lock contention problem. > > > > Patch 1 introduces the dlock list. The list heads are allocated > > by kcalloc() instead of percpu_alloc(). Each list head entry is > > cacheline aligned to minimize contention. > > > > Patch 2 replaces the use of list_for_each_entry_safe() in > > evict_inodes() and invalidate_inodes() by list_for_each_entry(). > > > > Patch 3 modifies the superblock and inode structures to use the dlock > > list. The corresponding functions that reference those structures > > are modified. > > > > Patch 4 makes the sibling CPUs use the same dlock list head to reduce > > the number of list heads that need to be iterated. > > > > Patch 5 enables alternative use case of as a set of hashed lists. > > > > Patch 6 provides an irq safe mode specified at dlock-list allocation > > time so that it can be within interrupt context. > > > > Jan Kara (1): > > vfs: Remove unnecessary list_for_each_entry_safe() variants > > > > Waiman Long (5): > > lib/dlock-list: Distributed and lock-protected lists > > vfs: Use dlock list for superblock's inode list > > lib/dlock-list: Make sibling CPUs share the same linked list > > lib/dlock-list: Enable faster lookup with hashing > > lib/dlock-list: Add an IRQ-safe mode to be used in interrupt handler > > > > fs/block_dev.c | 9 +- > > fs/drop_caches.c | 9 +- > > fs/inode.c | 38 +++--- > > fs/notify/fsnotify.c | 9 +- > > fs/quota/dquot.c | 14 +- > > fs/super.c | 7 +- > > include/linux/dlock-list.h | 245 ++++++++++++++++++++++++++++++++++ > > include/linux/fs.h | 8 +- > > lib/Makefile | 2 +- > > lib/dlock-list.c | 322 +++++++++++++++++++++++++++++++++++++= ++++++++ > > 10 files changed, 609 insertions(+), 54 deletions(-) > > create mode 100644 include/linux/dlock-list.h > > create mode 100644 lib/dlock-list.c > > > Is there other objections about merging this patch series? With the > additional patches 8 & 9 that I sent out on Oct 17, I think I had > addressed all the concerns that I received so far. Please let me know > what else do I need to do to make these patches mergeable? >=20 Hi Waiman, Have you read my email about the dlist_for_each_entry_safe(): https://marc.info/?l=3Dlinux-kernel&m=3D150831690725964&w=3D2 ? Regards, Boqun > Thanks, > Longman >=20 >=20 --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlnyhLcACgkQSXnow7UH +rjTRAf9EKEOqwehWPs/XQxHX78aQClWoL5CcLNSFzdSfiTti4vBdScZGy3Lja4q ywZEqU+i1ClBTSk/JT1u6LbHVMssiGhweLBZvWBbVxd7Pum0CIumbHm8ANsjzLz0 Tk/1XKI8nUHjUtBSbIvTEjzxsecFthtpC5BDBros6Pozdu2JRNpuDKSUgGAiCSG2 lwUOzOy+dYrZm90SnNfkIfFaXpBr4hOhJGe2CsDdUtxKA7PIK8ZWiH/Cv1uRKU5y Ixu+4B+p4JqDapLB21Ro72ipcna80WaY571e3pQOs62WCImNx+8b3pPS3QJUdsFY r3IdyPFke3P0JHVxVeS8voy92nAyhQ== =GLba -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn--