From nobody Mon May 15 19:14:06 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QKpvg6dPLz49ysD for ; Mon, 15 May 2023 19:14:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QKpvd3y5vz411Z for ; Mon, 15 May 2023 19:14:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ELKOKY6Z; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684178059; bh=0aJTkavWviQNntnKJNEnyMq8uAy9GuJit0F6/GZ1rw0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ELKOKY6ZMB3PrhGVEFTHQtDaQwlla8X12UF4D9IrNlKWk4xLHH/Z1yWaymO8Cfu2lV/Sfq5uGABwk9jEtL+nJi9ldMFCKpoiAmrDBBCO+4BkkKHpTDS/Ucownd6YVdtMtlBttlwvtchqS9n5Xu+zjFm4pwF5R/WNmuZ843V8o9c2XYIX13ygMZhe8nDPTe6fCHCG+liIChBd2Egb5zuoc5k1RJJEm1KwTh1O/ev4cWnw3a0OgZIXwspEg/XmSgPiNvQy98Tcj3HN2T4mf4I1AfXJBz94PY0Tn8NaYz+6G7tT+XURwH1LqpeFXUr5+fM9vpqGyHpP7RPFAaUvzsMHTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684178059; bh=fFN7KHaZtwkyU+rcIocszw2wslTHjST9/TaOx2T2oOD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DOfZgwsGdWirhHfEIRRV1vAvnZRNjIqKmzbBk0Cve1WBGAdaTwj4EfgDIKcOPvKpquSZFyI0soupnuwXTNsYQm/iyb+Z6ZsstPkLc4pMsmA5vfUkfN7IvCbAgAwS1/LbfZoTuEgruj+QSSsdUP1YhM9ZkFZD5V9uq1/zZHRxAy0hr1pCYLRSe+gm8j+cnMLN7Scr53p23Mj6SidAAEwLgAj6tk7s/HyoJ3wGnjl5qoWt7HhRXvFZzodlhHr9IjzdHJzNcZT12yZxbSc1d6+DM2+J5AOk6lFZDGBPdBezYlaH9WUN2J+lrpPBoIfw40XZYPDXjWjnInfqnh9oqep/qw== X-YMail-OSG: rZzDOwQVM1m.aPAJnWHh18C4eZdTGOdu7UDMFM5IV69h1p_X.qLz1dk1JqP.jvT ry1ESGcEJmWf3curJJ.WEcEaQocay34X6NYTeydokwBHLzOZQIG1VjypzpAwvt63Z58p38NBd_2B sUc0.2A5RfUuy4wXW0McJYRdiC7njkuEPWeTyD_MWjJqerbviN.jZREgbxVtrCFWFMzvQ4cwju4Z dsJal0AMF1cGVxVZ.Y.ZSkNcOEXR4g5pnPE452uuc..Qdf7ImXRmUQ5KvxfK_.WNF2HHeQZqid8A rNErh13Fmxww9DuMtvb74sN3zCulx94gUTbX1FIw7jjxOs.oPwWVPXV6R.Xro_XtQDJAiqbvbc80 Y3_9Zp1RO6JDZx5qHcXZ4jX9jNUmryLdH1i2M7dXDleW7jLeCI0Z6tdNzeKzcfqEuQOGJ_gEwHO2 6lDfbfZLfwEgUl5Zyr5U3x8RADSscESlZ3pcu0fUZl4EVlq3S2yG93FOqwiI3l.oEAlMe1uhMRdv 5WUe.WpQeYMBtfrxRPJNG4sfWVPAsq1Y1e36DcEeKPh3WA9X4VqROz68R196E3g2RN2Bh.BAsaC8 BWwair99x80hM7WRGSP4MB0e9oryU.kA1jGCMI_xX4P7VjAhlNndfKAoTxXbMnMhviNGgzg8yH2m 1FxYCvwvg3LtJXdCx9mm91DMVztJmU6uh5DKKfOUXntlbCh.RzeSVAafDu63kmw41W1n5BayHEOW 1SRlDhtEbJc5xa_VD88_KsHQYCQ3c94xso1sBaSwvYOAB2yS6faxaJNKanO7YUSWbSnssa7.1dp4 t4J6ktJKPFLiWkT3R._zqZY.o85vSUEX2_2mM99Z8OnXgeEsdhAjY0QqMyIkvegDO7GKm8pwT8vA uCwPOVTI3cQsHbmT.KTMDVi4CG7D7rkIkM0iQqQKRWwacR66VUFs.UfXsGhUMB5GD3JiJzwHmoJw 0O2kspLaDByfwcJYd9JpGYzRdIYdxJKj9NvJC7ScZFJpk4vJbnMXr4hNr5tPCRDzAi3HB1smJPDK YDEA3JlOV7TJEe8YYXyMhDpwySC.m2ukTR9UcTNSzOzviu6LZBGj4d93aIn9lPLONzdPQZQ7p8JC aO6UQJYfmYumrM4zQqROd.a45N_OucovPpC47vXVoDDsNw9P9VVT.0M5f50QCjb2u_zeZP2B3TH0 PKbFTFidrqJtUIHWWhTpx9OrgcDhyPHQT61WZxwnxU8XhOAepKtb1i1iPxzqryzW6ZwMjHf.pvoK 1doo0FllQl8SKJu7QV01y6ylSMyqduTnWyy8NavBx5mZhIAbeY6.zunAjQtCLGa84C5x0n.s2USu v6zgASaKK.pYI9mfnz8obgU.WDnWXwmMizBUeUT3p10KNoooyu0edp9qxjjv0mi7yolYp2iSY8c0 UAxHa1xxRCdRA1B0i_pcwYAazGhKawWj.cAluAyMDLL5Co1utwugWlbelqN.U6cPyQSK3QaHX5M. _6vdHt.w8EtviQnOVP6oUWYznQaY4YOzcShZDQg2wNYF2UIm7iz8HgzvPbtUI6aBuLmvJIXfBkl7 PX5aRkFJndYOWs.RUx1tBb1cwX7YqAMO1WhvCE1GE9cLyE_ixE.Zix7AFnRi2gQ_tKHET5kzRw6w WCNy87Jlg3y9Awod3BoHa2FQvULVzZf9YSfuYJC5y6VA30tAB1mpH4OW3CtrgxXg3et.S0nRtRvp 9_aRWrKKKExQIsWIp8Z3qEqUy7YYdhGlLHDC.v0jyqY_UZXF7_YLQD0muAeIyflYT3OpDo8SxJ85 BnBtW8tKyW__zdDG4WEDBKrb_r2.NpmEUgkUbh220AqMZEY.1SnEWrK9T4AQgN_hrj4VL.VEMQpr udo_7K4CZry7t763FWn.wdHwihPf_RSdu_mv7tEOZxN6phe4pMHL35qsGtC4wyKi5q8Vzw34c5QW AVvPiSw80aPdlCSz8KbZW_mibmoZ8xdTwlIqJA0EWSB.qUvRdgYv5rGbetWROgSpNfzNQ1jFcwDM wfCihDnvny345x5.xptmLrjmRKn3k.zqjLdPsNRz3rHO0iqJIWFNMfJa_7aXiSXNoIroVTjm3oOH z7G3Q5tRdg_n0sY.WX1.CqKibnpsMTRnUthqj.lwSgtdD9j_eH16ZK20CBPq4JWiJz3Ubpc5cRoA WgUsmOK.i3vafH0JOcBo5XahqNjNXkgiAWmesGgByOYC2sRQdbFDc6znPaDzdhaqf7tY.p4d0Gio waa1Q8l9UAbn.RCacIQWcDqbFZviKg0jZkifV_Brgv7g3Th79A.1dYpK2960jfM7eUMKNd1c2pMg - X-Sonic-MF: X-Sonic-ID: 5332199f-a968-42e0-9abd-8aaee810364f Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 May 2023 19:14:19 +0000 Received: by hermes--production-gq1-6db989bfb-hz24p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b58914027e833400d5ed5ce1870fd9e6; Mon, 15 May 2023 19:14:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Cores of different performance vs. time spent creating threads: Windows Dev Kit 2023 example From: Mark Millard In-Reply-To: <11EBAA22-6E0F-4B27-9799-7786E149D9B1@yahoo.com> Date: Mon, 15 May 2023 12:14:06 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <47DE0BF6-3A16-4F87-AEEF-6D320BBC90E5@yahoo.com> References: <11EBAA22-6E0F-4B27-9799-7786E149D9B1@yahoo.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.884]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4QKpvd3y5vz411Z X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On May 9, 2023, at 19:19, Mark Millard wrote: > First some context that reaches an oddity that seems to > be involved in the time to create threads . . . > > The Windows Dev Kit 2023 (WDK23 abbrevation here) boot reports: > > CPUs (cores) 0..3: cortex-a78c (the slower cores) > CPUs (cores) 4..7: cortex-x1c (the faster cores) > > Building a kernel explicitly via involving -mcpu= use > gets the following oddity relative to cpu numbering > when the kernel is used: > > -mcpu=cortex-x1c or -mcpu=cortex-a78c: > Benchmarking tracks that number/performance pairing. > > -mcpu=cortex-a72: > The slower vs. faster gets swapped number blocks. > > So, for -mcpu=cortex-a72 , 0..3 are the faster cores. > > This sets up for the following . . . > > But I also observe (a relative comparison of contexts > via some benchmark-like activity): > > -mcpu=cortex-x1c or -mcpu=cortex-a78c based kernel: > threads take more time to create > > -mcpu=cortex-a72 based kernel: > threads take less time to create > > The difference is not trivial for the activity involved > for this WDK23 context. > > If there is a bias as to which core(s) are involved in part > of thread creation generally, it would appear to be important > that the bias to be to the more performant cores (for what the > activity involves). The above suggests that such is possibly > not necessarily the case for FreeBSD as is. BIG/little (and > analogous?) cause this to become more relevant. > > Does this hypothesis about what type of thing is going on > fit with how FreeBSD actually works? > > As stands, I'm going to experiment with the WDK23 using > a cortex-a72 targeted kernel but a cortex-x1c/cortex-a78c > targeted world for my general operation of the WDK23. > > > Note: While the benchmark results allow seeing in plots > what traces back to thread creation time contributions, > the benchmark itself does not directly measure that time. > It is more like, the average work rate for a time changes > based on the fraction of the time involved in the thread > creations for each given problem size. The actual definition > of work here involves a mathematical quantity for a > mathematical problem (that need not be limited to computers > doing the work). > > The benchmark results are more useful for discovering that > there is something to potentially investigate than to > actually do an investigation with. > Never mind: Starting over did not reproduce the oddity. So: operator oddity/error, though I've no clue of how to reproduce the odd swap of which cpu number ranges took more vs. less time for each given size problem. (Or any other aspect that might be considered also odd, such as specific performance figures.) Retry details: I booted the WDK23 via UFS media set up for cortex-a72, media that I use for UFS activities on the HoneyComb (for example). I built the benchmark and ran it. As stands, I've only done the "cpu lock down" case. It produces less messy data by avoiding cpu migration once the lockdown completes (singleton cpuset for the thread). I'll also run the variant that does not have the cpu lock downs (standard C++ code without FreeBSD specifics added). === Mark Millard marklmi at yahoo.com