From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6D58C432C3 for ; Wed, 13 Nov 2019 21:26:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 95355206ED for ; Wed, 13 Nov 2019 21:26:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="LAn02cio" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95355206ED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 38CC86B0003; Wed, 13 Nov 2019 16:26:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 362C66B0005; Wed, 13 Nov 2019 16:26:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A0906B0006; Wed, 13 Nov 2019 16:26:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 1594E6B0003 for ; Wed, 13 Nov 2019 16:26:55 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id D0A3A440D for ; Wed, 13 Nov 2019 21:26:54 +0000 (UTC) X-FDA: 76152539148.14.ant36_3c37bf6d6154d X-HE-Tag: ant36_3c37bf6d6154d X-Filterd-Recvd-Size: 5810 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Nov 2019 21:26:53 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id l20so3189543oie.10 for ; Wed, 13 Nov 2019 13:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GXkcX2JCtyKHHo0cyAglaiWGhE2YBu5/DI/DhPu01Ow=; b=LAn02cio2MfDiRJwrNq18V3/ueYXDq6XkkbOMC9mIKr8Og4Hg9ge7OM8DRKJiQIHL/ bumdQzTlMxUhgjy/QBL0GW8zIJWFFWxIPImeU8EQmjwRcrbRTPhEisRh05HJxEKvRxjC HXLhoZ41YrOyPC/YB0HfY5kWYQVTDJ2bVWmEz4D4meNck4DWvbST6A9fRbgoliBURU0t 1W6rzDHt/Ofaa8L8fEoROHquPzJWNvWoBk7M28H4w4pFQIMmaoT7SelSj1/E13G2DdLg xGekDE5Vk1TeqpDeVVjIfYZJoJPFdS+FFh77Z2AUOJ0WB/YrzFEL6pmPSYxIFqQHQjt1 3AIw== 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:content-transfer-encoding; bh=GXkcX2JCtyKHHo0cyAglaiWGhE2YBu5/DI/DhPu01Ow=; b=mUcN1GjXtwIpSz8opYYrJPBANAQG4MUfCmWMv17MBxGHWRMKoINf266LZmhDZUoCot ajsvAx7rD2FT3OtLIop1j1NLja89PiI5vCnLzfi/6g7/yCF6J0mpimnu/t+BjrX0kd1R rhVgt9OyLArboTNv7iTUxTcrNH96dBasgmdgjVW27QERZmfxiYzG78byotRvA1KZHKCw YqCBzihhU4Y5+deZI09tKboE+uU2Fg+EfcXTTTyL5qus7w4X3a+0iejo4WHPVs+zNYup KJwA4YM9FMoiSVvkG0TxBofGLrtdlmabN7Moyi2npwACR1ANwpqE0RQw83h0YAzVCggG QD0w== X-Gm-Message-State: APjAAAW3eXYwRWZ2jcbrD8vbSWZT0sMlQxZQ86sqalHuqhYoKnJ70PFx Y9zi9odBc+AJP8IH0FMtynpXBOLKzJDw+nXbexLCOg== X-Google-Smtp-Source: APXvYqyDjhelVNRtH2Dd05TmcchN1KTJcyS9q6Qq71HSgmwdkipeSp+OhTiPzV+812M0dS2nt+KFP1CXO1g6gIoBsTo= X-Received: by 2002:aca:55c1:: with SMTP id j184mr653822oib.105.1573680412830; Wed, 13 Nov 2019 13:26:52 -0800 (PST) MIME-Version: 1.0 References: <3E71366A-9232-46BB-8261-3FCB2300C80A@redhat.com> In-Reply-To: <3E71366A-9232-46BB-8261-3FCB2300C80A@redhat.com> From: Dan Williams Date: Wed, 13 Nov 2019 13:26:42 -0800 Message-ID: Subject: Re: [PATCH 2/3] mm: Introduce subsection_dev_map To: David Hildenbrand Cc: Toshiki Fukasawa , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "mhocko@kernel.org" , "adobriyan@gmail.com" , "hch@lst.de" , "longman@redhat.com" , "sfr@canb.auug.org.au" , "mst@redhat.com" , "cai@lca.pw" , Naoya Horiguchi , Junichi Nomura , Oscar Salvador Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.023671, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 13, 2019 at 1:22 PM David Hildenbrand wrote: > > > > > Am 13.11.2019 um 22:12 schrieb Dan Williams : > > > > =EF=BB=BFOn Wed, Nov 13, 2019 at 12:40 PM David Hildenbrand wrote: > > [..] > >>>>>> I'm still struggling to understand the motivation of distinguishin= g > >>>>>> "active" as something distinct from "online". As long as the "onli= ne" > >>>>>> granularity is improved from sections down to subsections then mos= t > >>>>>> code paths are good to go. The others can use get_devpagemap() to > >>>>>> check for ZONE_DEVICE in a race free manner as they currently do. > >>>>> > >>>>> I thought we wanted to unify access if we don=E2=80=99t really care= about the zone as in most pfn walkers - E.g., for zone shrinking. > >>>> > >>>> Agree, when the zone does not matter, which is most cases, then > >>>> pfn_online() and pfn_valid() are sufficient. > >> > >> Oh, and just to clarify why I proposed pfn_active(): The issue right n= ow is that a PFN that is valid but not online could be offline memory (memm= ap not initialized) or ZONE_DEVICE. That=E2=80=98s why I wanted to have a w= ay to detect if a memmap was initialized, independent of the zone. That=E2= =80=98s important for generic PFN walkers. > > > > That's what I was debating with Toshiki [1], whether there is a real > > example of needing to distinguish ZONE_DEVICE from offline memory in a > > pfn walker. The proposed use case in this patch set of being able to > > set hwpoison on ZONE_DEVICE pages does not seem like a good idea to > > me. My suspicion is that this is a common theme and others are looking > > to do these types page manipulations that only make sense for online > > memory. If that is the case then treating ZONE_DEVICE as offline seems > > the right direction. > > Right. At least it would be nice to have for zone shrinking - not sure ab= out the other walkers. We would have to special-case ZONE_DEVICE handling t= here. > I think that's ok... It's already zone aware code whereas pfn walkers are zone unaware and should stay that way if at all possible. > But as I said, a subsection map for online memory is a good start, especi= ally to fix pfn_to_online_page(). Also, I think this might be a very good t= hing to have for Oscars memmap-on-memory work (I have a plan in my head I c= an discuss with Oscar once he has time to work on that again). Ok, I'll keep an eye out.