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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 21289C388F9 for ; Wed, 21 Oct 2020 13:17:02 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C31B20936 for ; Wed, 21 Oct 2020 13:17:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yY7Lv3oC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C31B20936 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xgCfu0EL3By9JZ4dvYZSZ9rqQVA5E1PGYWhVOnJ5Q6M=; b=yY7Lv3oC3Y2GTJ79G5riIkf+f q3yUCXBUZzJp4+bqPnoUuKE+DSB1GCQCRDPzbmn11XNylxIElOdRya53RKwyZ600vCJB5V/M4UJER RfFMWKZG/OJQRsIuYF2gIRKb+e9qGogAoy+4CIen46cQsaN19oSWJrZLTyYI9cnusgDINapdzoPCC ttHtkK/Ucrg1ULHDeSY0ypuhuRWIIMGHGFAv3L6pDsbAGuWOUVjWq6I7jsO18W2lCcQqKDhulKqWB mrLK3GbVf8RT/XFWRKrb2ju2kgfKdNaOU8AQTOCk41B+7Nrdd77ACNFn12/pInpV3l6BpXmE3zBM5 nM/I1btCA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVDxS-0003BS-Pp; Wed, 21 Oct 2020 13:15:14 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVDxP-0003Ak-Nu for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 13:15:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0E16131B; Wed, 21 Oct 2020 06:15:08 -0700 (PDT) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AFA733F66B; Wed, 21 Oct 2020 06:15:06 -0700 (PDT) Date: Wed, 21 Oct 2020 14:15:04 +0100 From: Qais Yousef To: Greg Kroah-Hartman Subject: Re: [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Message-ID: <20201021131504.vc3nbf2vt5dtiuva@e107158-lin> References: <20201021104611.2744565-1-qais.yousef@arm.com> <20201021112656.GB1141598@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201021112656.GB1141598@kroah.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201021_091511_878898_F7FD5E31 X-CRM114-Status: GOOD ( 28.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Will Deacon , "Peter Zijlstra \(Intel\)" , Catalin Marinas , James Morse , Marc Zyngier , Linus Torvalds , Morten Rasmussen , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Greg On 10/21/20 13:26, Greg Kroah-Hartman wrote: > On Wed, Oct 21, 2020 at 11:46:07AM +0100, Qais Yousef wrote: > > This series adds basic support for Asymmetric AArch32 systems. Full rationale > > is in v1's cover letter. > > > > https://lore.kernel.org/linux-arch/20201008181641.32767-1-qais.yousef@arm.com/ > > That is not good, provide full rational in each place, not everyone has > web access at all time. Sorry. I usually copy the whole thing but for the first time I do this as I thought it'd be better to be less wordy. I'll copy the whole thing again next time. > Also, you forgot to document this in Documentation/ABI/ like is required > for sysfs files, and I thought I asked for last time. Last time there was no sysfs info. It's introduced for the first time here. There's still no consensus on which direction to go, that is fix it in the scheduler or let user space handle it all. > > Changes in v2: > > > > * We now reset vcpu->arch.target to force re-initialized for KVM patch. > > (Marc) > > > > * Fix a bug where this_cpu_has_cap() must be called with preemption > > disabled in check_aarch32_cpumask(). > > > > * Add new sysctl.enable_asym_32bit. (Catalin) > > > > * Export id_aar64fpr0 register in sysfs which allows user space to > > discover which cpus support 32bit@EL0. The sysctl must be enabled for > > the user space to discover the asymmetry. (Will/Catalin) > > > > * Fixing up affinity in the kernel approach was dropped. The support > > assumes the user space that wants to enable this support knows how to > > guarantee correct affinities for 32bit apps by using cpusets. > > I asked you to work with Intel to come up with an agreement of how this > is going to be represented in userspace. Why did you not do that? I did chip in to that thread. AFAIU they're doing something completely different and unrelated. Their goal is unclear too. They care about big.LITTLE type of support for Intel and collating already existing information in a different/new place. I don't see the point. I saw they had several similar comments from others. They need to send a new version to see if anything changes. > Without even looking at the patch set, this is not ok... Sorry about that. Please keep in mind we're still debating if we want to support this upstream. And if we do, what shape this should take. My first version highlighted how things could look like if scheduler took care of the problem. Now this RFC tries to highlight how things could look like if we go with pure user space based solution. It's to help maintainers get a better appreciation of what implementation details incurred in either direction. At least that was my intention. I'll improve on the cover letter next time. Thanks -- Qais Yousef _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel