From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753864AbdKXWCo convert rfc822-to-8bit (ORCPT ); Fri, 24 Nov 2017 17:02:44 -0500 Received: from mondschein.lichtvoll.de ([194.150.191.11]:52819 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753730AbdKXWCn (ORCPT ); Fri, 24 Nov 2017 17:02:43 -0500 From: Martin Steigerwald To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox Subject: Re: XArray documentation Date: Fri, 24 Nov 2017 23:02:41 +0100 Message-ID: <7001154.REmHhS1LlQ@merkaba> In-Reply-To: <20171124211809.GA17136@bombadil.infradead.org> References: <20171122210739.29916-1-willy@infradead.org> <2627399.jpLCoM7KBo@merkaba> <20171124211809.GA17136@bombadil.infradead.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Matthew Wilcox - 24.11.17, 22:18: > On Fri, Nov 24, 2017 at 07:01:31PM +0100, Martin Steigerwald wrote: > > > The XArray is an abstract data type which behaves like an infinitely > > > large array of pointers. The index into the array is an unsigned long. > > > A freshly-initialised XArray contains a NULL pointer at every index. > > > > Yes, I think this is clearer already. > > > > Maybe with a few sentences on "Why does the kernel provide this?", "Where > > is it used?" (if already known), "What use case is it suitable for – if I > > want to implement something into the kernel (or in user space?) ?" and > > probably "How does it differ from user data structures the kernel > > provides?" > > OK, I think this is getting more useful. Here's what I currently have: > > Overview > ======== > > The XArray is an abstract data type which behaves like a very large array > of pointers. It meets many of the same needs as a hash or a conventional > resizable array. Unlike a hash, it allows you to sensibly go to the > next or previous entry in a cache-efficient manner. In contrast to > a resizable array, there is no need for copying data or changing MMU > mappings in order to grow the array. It is more memory-efficient, > parallelisable and cache friendly than a doubly-linked list. It takes > advantage of RCU to perform lookups without locking. I like this. I bet I may not be able help much further with it other than to possibly proofread it tomorrow. Thank you for considering my suggestion. -- Martin