Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp166123ybl; Wed, 21 Aug 2019 16:54:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1F9iD3LhztPtMsg5PsmkYqi+USzz8eXt9IqKBYTt5280JlPk699+CB/kcVtlT+TNEYHwL X-Received: by 2002:a65:68c9:: with SMTP id k9mr30655021pgt.17.1566431655385; Wed, 21 Aug 2019 16:54:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566431655; cv=none; d=google.com; s=arc-20160816; b=XFHdyQ0jDknsMWgp8Cf5SkrY/FOYUNFhxwLISix1L12bzgPyxuS4LY1+9Q72TGOdcI PgeM+yOlpl7E/bsNyiUFzZ5Ta24jiERcKtgCYLYrr0j7zj6iYbQ8HNMbPb2RUhpr7xTe vr+p0qJxt4ztvH23kr1eVm+d6aIpa5e67ZuOa8wYAMg86KgBpBWbTLZXXw35qQN0g85v 423s9PRwM4CsS8/9ccHD8iRScOtQFKC4WsimOiu6GGUlxG00RhEQkssoaR7deMiS76tk LDnf6vuSt+JqNUK9eh8+nvupvQ1Ot2oO/f+ZDQAh8zGETV0h6alvXYdSL49qUv6FdLDe pQLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=uRWHH/aM+UkPunAeZEcYoWrVH4+5skxbUg+WumsRgVA=; b=vN7a1SJJkMbLMKqdpjZNbMERi2iYdADOEqZshhup1gRBkFhBA2KVNTnuhD+BcwRUwW 1sUR+Rqjo74gnP9oMm24jE/A99TROt6iBoVmkeoa3qiwU7UWCZr3xQWkcuxi5cQUcWSR DbZxGHotEeBNSV12aIy/r9xhj/qsfe7Q4jo48LCAS4YxCQHKwqWN3GZRuQV2lAJSQ51W /3blO64GZz25f9aBjoH6Z1eCejN9JAkD8CHnr61eyKTCxqdvxPNyPhuL5SAK3mFVqWHo g8Q5dglQDfr+UT59ZL84dg4GOxJ468oA86euLZDMeJQlLIJDtpbhTzrwnoLZXiGBB+kU 1tMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XtzUgNUM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v8si16875496pfm.83.2019.08.21.16.53.59; Wed, 21 Aug 2019 16:54:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XtzUgNUM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729666AbfHUWSS (ORCPT + 99 others); Wed, 21 Aug 2019 18:18:18 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:46122 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729168AbfHUWSS (ORCPT ); Wed, 21 Aug 2019 18:18:18 -0400 Received: by mail-pl1-f195.google.com with SMTP id c2so2104044plz.13 for ; Wed, 21 Aug 2019 15:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uRWHH/aM+UkPunAeZEcYoWrVH4+5skxbUg+WumsRgVA=; b=XtzUgNUMdbn+u28A49CH+Fcb4+5NG6wGPAdq2AbB4sJce30mABw9IZ91C2OoBtQmPT 1wai5Q5IauNOff/9NU/6X8bDfc4tRI8v5Gy8YouagyzD4J5wS+IgfZK2Fz0Bnm7UW4VW 6vDrZ+IXSjxoeF1UvAYMJqxklW88OErPfGZxjtVBpLfUBZoH6fY8o9/zGk+sAkvTnZgh oQ51I6L0ZrHD/xe49onARlEvlcfccpy/Ba1n8TkKA/NgozcxReNxSEtqKJOe+ThEu0Hd CyaejOjbCTcvijgnq3nok3FNLdOYE5kFCR8gGYyXPVC87I6+h92hqpz+Ep6NARlyZBes UK5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uRWHH/aM+UkPunAeZEcYoWrVH4+5skxbUg+WumsRgVA=; b=EMgtV23Tg+LK/KxPUa3UfCTCnSMmcsb4c8oA99qjpdxQLOoEVqOHCVkLD2h7nrATtK l2Ru1inWeI56oxZTKu+x1veI65xJhiD8tgGfeXzBwTJdn4pUUznaM60cNAXOxOTI669W TDPKvbZgO0P0muuw8LvhwgdHzvUZj08M0FvLBqb2iRb7aLRwknecy9uLPKqKEbX2gYGA TVKrHTGnPHbcTkxO1G0H2+dtXqqnUvbBC6c1mD3U/jeP4NAPiFeD2E3lCMXeVsx4bwts +2sKUeCqNLCWK1HmZhtmkynR61VicbgLeMYtEtxUmf6E9DI36r0MlLF87vhnp0CohkKY v4NA== X-Gm-Message-State: APjAAAXh05YbWpkFJAMR3CkpO4aQAPyj35rvhSxWZS53s0lxMoE3Ru9V T/U4NYT1Qqjj/GvEbsjYGuQldw== X-Received: by 2002:a17:902:f096:: with SMTP id go22mr36907820plb.58.1566425896980; Wed, 21 Aug 2019 15:18:16 -0700 (PDT) Received: from google.com ([2620:15c:2cd:202:668d:6035:b425:3a3a]) by smtp.gmail.com with ESMTPSA id a11sm848491pju.2.2019.08.21.15.18.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2019 15:18:15 -0700 (PDT) Date: Wed, 21 Aug 2019 15:18:14 -0700 From: Michel Lespinasse To: Davidlohr Bueso Cc: Peter Zijlstra , David Howells , Andrew Morton , LKML Subject: Re: [PATCH v2 2/3] augmented rbtree: add new RB_DECLARE_CALLBACKS_MAX macro Message-ID: <20190821221814.GB99147@google.com> References: <20190702075819.34787-1-walken@google.com> <20190702075819.34787-3-walken@google.com> <20190702160913.ptg4p2jyb6ih43hb@linux-r8p5> <20190814000616.sd4mxwsewhqqz6ra@linux-r8p5> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190814000616.sd4mxwsewhqqz6ra@linux-r8p5> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 13, 2019 at 05:06:16PM -0700, Davidlohr Bueso wrote: > On Tue, 02 Jul 2019, Michel Lespinasse wrote: > > - The majority of interval tree users (though either the > > interval_tree.h or the interval_tree_generic.h API) do not store any > > overlapping intervals, and as such they really don't have any reason > > to use an augmented rbtree in the first place. This seems to be true > > for at least drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c, > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, drivers/gpu/drm/drm_mm.c, > > drivers/gpu/drm/radeon/radeon_mn.c, > > drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c, and probably > > (not 100% sure) also drivers/infiniband/hw/hfi1/mmu_rb.c and > > drivers/vhost/vhost.c. I think the reason they do that is because they > > like to have the auto-generated insert / remove / iter functions > > rather than writing their own as they would have to do through the > > base rbtree API. Not necessarily a huge problem but it is annoying > > when working on inteval tree to consider that the data structure is > > not optimal for most of its users. > > I think the patch I sent earlier will add to your unhappiness. Not really, I think the pat conversion is a good idea though I am confused about the interval definitions (open or closed ?) in your patch set. > > - The intervals are represented as [start, last], where most > > everything else in the kernel uses [start, end[ (with last == end - > > 1). The reason it was done that way was for stabbing queries - I > > thought these would be nicer to represent as a [stab, stab] interval > > rather than [stab, stab+1[. But, things didn't turn out that way > > because of huge pages, and we end up with stabbing queries in the > > [stab, stab + page_size - 1] format, at which point we could just as > > easily go for [stab, stab + page_size[ representation. Having looked > > into it, my understanding is that *all* current users of the interval > > tree API would be better served if the intervals were represented as > > [start, end[ like everywhere else in the kernel. Do you have any thoughts about changing the interval tree definitions to use half-open intervals like everywhere else in the kernel ? -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.