Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp807855ybh; Wed, 11 Mar 2020 11:13:42 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvey3HZCb2DfawWCSH6dePVK6Qq4exb68vvkGLBaGYW+DZ/8pFXVQAG9KIJAXvEonmtO+lL X-Received: by 2002:aca:b9c2:: with SMTP id j185mr2735196oif.112.1583950421837; Wed, 11 Mar 2020 11:13:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583950421; cv=none; d=google.com; s=arc-20160816; b=zU/53JPbUHams+W06Rgaoek3lDQopDuQ9enoDmhho4PFYfaVbwQ7eKI/fiengY6KHk K8JyCo1n6/ngOo4re6zLs/pm1P7uM6wgfonVcK80bzo5k2u+VArBozstZ+2iaRhvZbco yiLjAqf4s/uMveXpvaiNKveC6ILLUn+JKis0blyVermeVUNdUP2pFvJt9wVcV4ZR8JY+ U94SoAgewiNfUm3onLu7tZ3gq/XNS77uEReRkV3bQXHz2sadha3tQoHQni0QVco7yijR AQK73EAHxwtnt/3TSRYwTYTbrzi/Nx3qCiroDfDIbXwlwrNbuuiiKCPEQE2ydlbKt8V2 BEbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=rJoCqv3sRaC/L2EG6NMpUbNiI4W5EMGXUoloMUmW+0Y=; b=g+EOZSlG7LUFYn+UcijrLSD6RbziyCxw895865RgnRUEOXJtwn/5LHxOuxdfO+qqbF mSwVGyvv69rMDf8oMZsh0UDW8P2KOaoJKh6jZy8VKfJ+oPpdeibyJbZTE/f2s7bNnmx8 Fc8BoHElPRtSIaKT2e9pYO7aCDFb0tSCVRhE2z3Z+OdSAN37qajEDLMpk4ib+RK7q1V7 DwTyeS4L5K2IEVmppRel1hppocB9gX/og70K0HEfjojrnPJA/vYwpVhYJPa0IV7rGxvh c2+LBJZtMqxFjZVDRVU2J5+4HmMVf96bczb6Qwwdj3ariHkZF+HYCnvEelocUI3SFjgV e0mQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si490449ood.43.2020.03.11.11.13.23; Wed, 11 Mar 2020 11:13:41 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730674AbgCKSMh (ORCPT + 99 others); Wed, 11 Mar 2020 14:12:37 -0400 Received: from mga12.intel.com ([192.55.52.136]:55536 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730468AbgCKSMg (ORCPT ); Wed, 11 Mar 2020 14:12:36 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2020 11:12:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,541,1574150400"; d="scan'208";a="261223466" Received: from sai-dev-mach.sc.intel.com ([143.183.140.153]) by orsmga002.jf.intel.com with ESMTP; 11 Mar 2020 11:12:32 -0700 Message-ID: <32b35b12e5e80f309f45b3a17a8d681e7e1fa33f.camel@intel.com> Subject: Re: [PATCH V1 11/13] selftests/resctrl: Change Cache Quality Monitoring (CQM) test From: Sai Praneeth Prakhya To: Reinette Chatre , shuah@kernel.org, linux-kselftest@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, tony.luck@intel.com, babu.moger@amd.com, james.morse@arm.com, ravi.v.shankar@intel.com, fenghua.yu@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org Date: Wed, 11 Mar 2020 11:07:45 -0700 In-Reply-To: References: <26086dda86f062bba4116878a012a553503924b2.1583657204.git.sai.praneeth.prakhya@intel.com> <04c252f59062450e14642fcbef4b85845f6a7427.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-0ubuntu0.18.10.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On Wed, 2020-03-11 at 11:03 -0700, Reinette Chatre wrote: > > > > > > [SNIP] > Hi Sai, > > On 3/11/2020 10:33 AM, Sai Praneeth Prakhya wrote: > > On Wed, 2020-03-11 at 10:19 -0700, Reinette Chatre wrote: > > > On 3/10/2020 7:46 PM, Sai Praneeth Prakhya wrote: > > > > On Tue, 2020-03-10 at 15:18 -0700, Reinette Chatre wrote: > > > > > On 3/6/2020 7:40 PM, Sai Praneeth Prakhya wrote: > > > I missed that. Thank you. > > > > > > fyi ... when I tried these tests I encountered the following error > > > related to unmounting: > > > > > > [SNIP] > > > ok Write schema "L3:1=7fff" to resctrl FS > > > ok Write schema "L3:1=ffff" to resctrl FS > > > ok Write schema "L3:1=1ffff" to resctrl FS > > > ok Write schema "L3:1=3ffff" to resctrl FS > > > # Unable to umount resctrl: Device or resource busy > > > # Results are displayed in (Bytes) > > > ok CQM: diff within 5% for mask 1 > > > # alloc_llc_cache_size: 2883584 > > > # avg_llc_occu_resc: 2973696 > > > ok CQM: diff within 5% for mask 3 > > > [SNIP] > > > > > > This seems to originate from resctrl_val() that forces an unmount but if > > > that fails the error is not propagated. > > > > Yes, that's right and it's a good test. I didn't encounter this issue > > during > > my testing because I wasn't using resctrl FS from other terminals (I think > > you > > were using resctrl FS from other terminal and hence resctrl_test was > > unable to > > unmount it). > > I was not explicitly testing for this but this may have been the case. > > As a sidenote ... could remount_resctrlfs() be called consistently? It > seems to switch between being called with true/false and 1/0. Since its > parameter type is boolean using true/false seems most appropriate. Agreed and make sense. I will fix this in a separate patch. > > I think the error should not be propagated because unmounting resctrl FS > > shouldn't stop us from checking the results. If measuring values reports > > an > > error then we shouldn't check for results. > > This sounds right. It is inconsistent though ... the CQM test unmounts > resctrl after it is run but the CAT test does not. Looking closer the > CAT test seems to leave its artifacts around in resctrl and this should > be cleaned up. Yes makes sense. I will fix CAT test to cleanup things. > I am not sure about the expectations here. Unmounting resctrl after a > test is run is indeed the easiest to clean up and may be ok. The main reason for unmounting is that assume user hasn't mounted resctrl FS before running the test then we want to make sure we get back to the same state as before running test and also to clean up any changes made to resctrl FS during test. > It may be a > surprise to the user though. Perhaps there can be a snippet in the > README that warns people about this? Sure! makes sense. I will add it. Regards, Sai