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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E093EC43215 for ; Sat, 16 Nov 2019 20:45:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 82B7220729 for ; Sat, 16 Nov 2019 20:45:37 +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="P2n5ewmA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82B7220729 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 D24146B0003; Sat, 16 Nov 2019 15:45:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD5DA6B0006; Sat, 16 Nov 2019 15:45:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEA246B0007; Sat, 16 Nov 2019 15:45:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id A8E766B0003 for ; Sat, 16 Nov 2019 15:45:36 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 5DDE38249980 for ; Sat, 16 Nov 2019 20:45:36 +0000 (UTC) X-FDA: 76163321472.23.coast58_13a4249998010 X-HE-Tag: coast58_13a4249998010 X-Filterd-Recvd-Size: 5361 Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Sat, 16 Nov 2019 20:45:34 +0000 (UTC) Received: by mail-ot1-f48.google.com with SMTP id n23so11064792otr.13 for ; Sat, 16 Nov 2019 12:45:34 -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; bh=2dZwnfQgOqTIKiwRnj4r9Zker73mZIhEC1hZOmrCLBY=; b=P2n5ewmAguqGNxt28KAgF0903BwywKKX71aXiOgk8/c0eldQ2jXd+vpyikAxMbFuwa cgkfCGt55N4UizeGQE740p+dLfFqfdvMTxR8RHHcY9B2xt9htdDU4c8Dan1gWbNj1K1j Q/78fhEUiImeG9rQ84yjekUFxTYhA5QfSQNDe7znRxL5wBVhdZEgLeo3vpJbpqPlZ0Yu VD2gAunlUhaLDpT65i+5Sx5ZVmbUNRXT9B29hH09QeA91wpG0f+RsdYtzZL+dZSCy6XV e06bX98qpXzWtB8hrOTk6z5yzcy4QqR0E7/mPnGv9s2FGHqwB8LRMVq4Aq64tRu5C77C TVIQ== 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=2dZwnfQgOqTIKiwRnj4r9Zker73mZIhEC1hZOmrCLBY=; b=s0w7zrJs3+gq6QNCyg/m/pQ4jAT5xuDtJJAAfIbvYGRbZBO1BMmII86Xd1NCI0oJ9n 0HERQDa7ZfU5BRNZN1Op3ZI0/2gdP1cJ6m6YMLymvI42ctBc6NNg2jOCYlxHcexwRGIK +auWp0A198FcwaEHgwo5AqATeclr5TaXYSlfa6zywMkWE8vmWm+dF1jmNqIq49ydjJfT vPYdtz6WD4Uzm9G6nZbIDLKQUa+dURcUn26u1qEd0rjda56s2qYCBItdVyxMQ1GWq1cZ C+dvMpJyn3+yq6tiYoFESqPSh5TVcLNSd1c+foCSqjFf0wC2AOFDj0dZYvCOpXW78HCb V8yA== X-Gm-Message-State: APjAAAWztsWatYHWCIWTTcK8BWM3m6MWPdkRCzRjWGPs50vPiSHlqwXU qSGpCehlLcFeigyUnzWzyPfw/pzXjtg+xDRYBfHd/A== X-Google-Smtp-Source: APXvYqw/01RAS5kPKwQvBvbyIGf6pNqFTax9GSBdKiLyr9qfJ555nkMjEqS9rdk3Ii2GR4w3V4jwlChgzmNvsgnybsY= X-Received: by 2002:a9d:30c8:: with SMTP id r8mr17204216otg.363.1573937133999; Sat, 16 Nov 2019 12:45:33 -0800 (PST) MIME-Version: 1.0 References: <20191004114330.104746-1-Jonathan.Cameron@huawei.com> <20191004114330.104746-2-Jonathan.Cameron@huawei.com> <20191113094742.00000dc4@huawei.com> <77b6a6e8-9d44-1e1c-3bf0-a8d04833598d@intel.com> <20191113174845.000009d3@huawei.com> <20191114112504.00005b61@huawei.com> In-Reply-To: <20191114112504.00005b61@huawei.com> From: Dan Williams Date: Sat, 16 Nov 2019 12:45:23 -0800 Message-ID: Subject: Re: [PATCH V5 1/4] ACPI: Support Generic Initiator only domains To: Jonathan Cameron Cc: Tao Xu , Linux MM , Linux ACPI , Linux Kernel Mailing List , Linux ARM , X86 ML , Keith Busch , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , "Rafael J . Wysocki" , Linuxarm , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Nov 14, 2019 at 3:27 AM Jonathan Cameron wrote: [..] > Hi Dan, > > Agreed that it makes sense to expand how we describe these cases a bit. > To make sure I've understood correctly let me paraphrase what you > are proposing (and tweak it a bit ;) > > Assuming for this purpose we don't put GIs in CPU nodes as that makes > for really fiddly explanation. In reality the code will need to handle > that. > > 1) Leave access0 as it currently is with this series - so continue to > not distinguish between CPU nodes and Generic Initator containing ones? Yes, but with the caveat that I think 2) also needs to be part of the series before it goes upstream. I.e. don't regress the amount of default information just because a generic initiator is present. > 2) Add access 1 which is effectively access0 ignoring Generic Initiators? Effectively yes, but I'd say it differently. Always display the access class for the local initiator as defined by the HMAT as access0, but also include the "local" cpu node. > My feeling is that any existing users of access0 are definitely not going > to be expecting generic initiators, so we might want to do this the other > way around. access0 is only CPUs and memory, access1 is including > generic initiators. If there are no GIs don't expose access1 at all? There are no consumers of the information that I know of, so I do not see the risk of regression. > For now we could simply block the GI visibility in access0 and deal > with access1 as a separate series. I suspect we will get push back > as there are no known users of our new access1 so it may take a while > to prove utility and get it accepted. The problem is that HMAT gives an unequivocal answer for "local" because it lists it in the table explicitly. Everything else is a subjective determination from parsing the performance data and picking a metric. If access0 is a GI, then let sysfs just reflect that truth.