Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp312606ybl; Fri, 23 Aug 2019 01:01:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGW3l74t1ZolE6oF+xzN1mbtla0OH9/evSCbaEZckqhVennO0SM/nj3iUR7jAWt/ea5j8U X-Received: by 2002:a62:4d41:: with SMTP id a62mr3702002pfb.155.1566547269170; Fri, 23 Aug 2019 01:01:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566547269; cv=none; d=google.com; s=arc-20160816; b=SVG5Z22hfQ0oC0Pf5vJTLDzediM2EfUB1ic5/tTkxuHOb+3lqx7UlS0+uXdZAZWQ2W sssf8GBKzmmah5STlNVj84fA0U/abort36eK8BlSrDvT2NOcgONxBfh03D7HbAcxTesz 767QwsdgvHc2C9cQnjTgW6BPEIGYHk6XCWHFR/vyvfrsAl2U2g/LiDDYiTjtd9k1MFzl bcxQODTJKmx4tAU0TOtsrlP5aQC0n4o8bGgphDgVMnnn4FaFMmTX46Ddl+/p2mS4xp8N X90EvgNIWtdxau8pW9Zhnmzrmn1a/P8yWZl/adGe+28gI/XCUz22Vmlp8JNeprTapNq8 SU5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RZqoQbOf4zkZDFdaVNZEkUCJ//n9bEGb3Yhu+Zzx41M=; b=pPylXLKy3OZ6YkhMv3z0bF1tCliWoNj/lHGdGB6tIXNzcJClRyXKGEO9Nk3rzoAHRP QaASJWFy+NtAbLHslF4CJVbY+oqoQoTMOg7J3yeK3Q4geNGgGfxBCVLnjCqAkT2qxXS+ VsfZQiu341xSgesNgOvdDRVhQGfpv/7PuKm0x/zKSsY1uI/V2/+3MRGKwYaix0iSez0x sSdz3XWa9kHYMABEOOnbY/caFuAKCx1TL+qCNV5VwRE0nb6keQficQtg0/jnXYoWbV3k tH1OSTVfPEvG+3uR9A1nQDeOQ+oTTHTKEjsC6b5sJWd92YHHlDrVYsmw/3cPxnBY/JIp 76dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=k+P8YtlA; 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 72si1970372pfx.268.2019.08.23.01.00.54; Fri, 23 Aug 2019 01:01:09 -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=k+P8YtlA; 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 S2392786AbfHVUKv (ORCPT + 99 others); Thu, 22 Aug 2019 16:10:51 -0400 Received: from mail-ua1-f66.google.com ([209.85.222.66]:45461 "EHLO mail-ua1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388453AbfHVUKv (ORCPT ); Thu, 22 Aug 2019 16:10:51 -0400 Received: by mail-ua1-f66.google.com with SMTP id w7so2439291uao.12 for ; Thu, 22 Aug 2019 13:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RZqoQbOf4zkZDFdaVNZEkUCJ//n9bEGb3Yhu+Zzx41M=; b=k+P8YtlA1ApmcGbTff68psOOylvM4LkDknvXY1D32vTQEiLrTd4AaL/LIbZl4ctGXk Ahm+qeTbLaDuoS0unujJos/Yqr1TufWPSWlXeNQIf0QSJFg2o25uLVT6C1Kh1UbaM8Q7 E9AsnbcSFMmzdOEXAy6aiuP8DYXaekq1VXxtEfkTO1FktJbkV+LLlIa8IjOKfLtW+3e4 jgqFdsiaEqrFP9u9SHtcn82AlxUStaWekeG0VZy7Usw/1ot+gnkvGgvc06nDbdbuH1RE Vloyw1QETGYZhh4P+fSXRZBpR7GLQ96n0MBJ3bD9/iOCi9ZyJl3y1RmYbqe8k28TItEW ML0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RZqoQbOf4zkZDFdaVNZEkUCJ//n9bEGb3Yhu+Zzx41M=; b=eZd8fpbnwX1hAJTR0Sh1Jh8CePeU56ThtXQKpuPq2Zdfu1036fq25GnC0qGdgE1GD2 T7nVntWHUELc4bgr1u1nhofN1V+YnsiS0YFyb5vUYgL44wDqPBrMgnnyURwzRqJ/rmrx 9FbKVB+5iQjVpmADJ/QCTEU+vAwbUjdy4onfhVurTKqfsTeAxv4Q/WgTcbkKjf/5meYN 1r8E/TC+PcILwo7epWqOELB94jbx+rqc1veqH6SXSn449J/Wp4jAEhsqMRRLigAdIxMW YNYdy+wnU0GILEs/WgdainEJxgw0QLEw3RyWSUmV3Axt3dZ5maaDahponpsRJMooBDLe VCVg== X-Gm-Message-State: APjAAAUJdTzZ/80E96ucOYp3kI2ScebrdsxnS9LUmLaRtHmHCXYe99uD lZjlLb/MMS3duZnml3zStRODw94Lhi4wKyG3MfEmFw== X-Received: by 2002:ab0:45e7:: with SMTP id u94mr923927uau.47.1566504649512; Thu, 22 Aug 2019 13:10:49 -0700 (PDT) MIME-Version: 1.0 References: <20190813224620.31005-1-dave@stgolabs.net> <20190813224620.31005-2-dave@stgolabs.net> <20190821215707.GA99147@google.com> <20190822044936.qusm5zgjdf6n5fds@linux-r8p5> <20190822181701.zhfdkjbwjh56i3ax@linux-r8p5> In-Reply-To: <20190822181701.zhfdkjbwjh56i3ax@linux-r8p5> From: Michel Lespinasse Date: Thu, 22 Aug 2019 13:10:37 -0700 Message-ID: Subject: Re: [PATCH 1/3] x86,mm/pat: Use generic interval trees To: Davidlohr Bueso Cc: Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Andrew Morton , x86@kernel.org, LKML , Davidlohr Bueso Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I think vma_interval_tree is a bit of a mixed bag, but mostly leans towards using half closed intervals. Right now vma_last_pgoff() has to do -1 because of the interval tree using closed intervals. Similarly, rmap_walk_file(), which I consider to be the main user of the vma_interval_tree, also has to do -1 when computing pgoff_end because of the interval tree closed intervals. So, I think overall vma_interval_tree would also more naturally use half-open intervals. But, that's not a 100% thing for vma_interval_tree, as it also has uses that do stabbing queries (in arch specific code, in hugetlb cases, and in dax code). On Thu, Aug 22, 2019 at 11:17 AM Davidlohr Bueso wrote: > > >On Wed, 21 Aug 2019, Michel Lespinasse wrote: > >>As I had commented some time ago, I wish the interval trees used [start,end) > >>intervals instead of [start,last] - it would be a better fit for basically > >>all of the current interval tree users. > > So the vma_interval_tree (which is a pretty important user) tends to break this > pattern, as most lookups are [a,a]. We would have to update most of the > vma_interval_tree_foreach calls, for example, to now do [a,a+1[ such that we > don't break things. Some cases for the anon_vma_tree as well (ie memory-failure). > > I'm not sure anymore it's worth going down this path as we end up exchanging one > hack for another (and the vma_interval_tree is a pretty big user); but I'm sure > you're aware of this and thus disagree. > > Thanks, > Davidlohr -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.