From nobody Wed Dec 07 21:42:24 2022 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 4NS9kF4Mfdz4jvZW for ; Wed, 7 Dec 2022 21:42:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.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 4NS9kD4S4Cz3vSB for ; Wed, 7 Dec 2022 21:42:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GitM+0bf; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.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=1670449362; bh=lZq2+/+6CEjGzdHchUUJHZp1nf1dJ04iaVcLRbNvrn8=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=GitM+0bfJ23Bu+xA7oNjsNydGovZSDFQ3pkSkmWQU8tSwBl9dcjexljx205l58U0bL27cklpBnJtmd8TcKZOKUVav7+eP9CO2JH62WlwqoQmQS4Js3XWTmmskW1XOtDgxPQdC3u8L5sgl0SrW6F2bQlyxxexMDD0TnTspFSStF0DF9TMY4p6cbhqvO8IzZdFOMh2icnFn9kKF2C8rmpJwVpbg8r7hYHTo9qW6NXJldVtPrpPgRWXbj0C5r5J3gsF7zBOy6mpk6conSB5hYV+h8ES654WrwoLJEqiQsQnXMvs5tHvZeNcACYgeJxGEuKSWqJtes5ZYsr97OZqYdxdcQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670449362; bh=sSrOW6tHQZw+ZS9f2tw8E8s2zxZ5z8tAUtkMOZp2ZMZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FQ7PVoyLKgXizdgslZqhD8A5nzSAx9MjY7uF/07FCo6kK4Kc5Xd2uYxZqDI4BrnhHjIsUyo1xjm2Z79F8ZtxgxsSNjSubCvuIbBp/RoRCgRTZGQKYePut5KMbEnzru+Ulgn1ultaLYNPG5ConmfvutITCh52If78qFKZfswbiLGOH9m1gtX1JTWSw2BU7wubO+x3l7L+jZyshqN/N7YwWIK62AlRkL8/FcfODCJBAjQykRjvlDbFUFFMyhMY1rc7OUTEb/2eZkXSBd7NkPXqDNZXd2hhOxbSfnHwPgEGn60sjj3ZFhwhKR1qyTmtdMqjShmA9BF/lKD+osqHPXqj2A== X-YMail-OSG: oOlFPF0VM1mkzTOEbwZtjCZDuTy_I0LL_rpjEp6dic7Dm8hX3N87VzMw_djmrf. Iaqfn62SExIRqPrrZO8y8v3DGGaFa6wVG0AQ__DZGWn30p4.rK5HefN53yiC7ijEz6iSO0ETqoN7 JQDz8m5rXr8au.FhEivMjxv9eXo2tVulQD3aYR6cy5U5O.HL2iZ31EUTdizD59XGnam.h4bYcFWD 4Cu2Ci190ydmuyKVP0YTJqAt5wi.2IZPE1pCwUGq2E442HatLlqMUnbIJxldUFhbNi9amzIcTeLJ swNB_Nr38jBgdsw1MdifDyEpsDkiJQnoovkgMWqfC.md52Li1OkvO0Kx4Qgb1VASAjEyqVHFyJRH JZ0jUUUNeK2CF3cx8l02mJISLCqJuD6mShnCkJ0PzVYTW0WsQqFIfa6W4Kxgs_KbWK2WzR6e1QOm TvgT0pvdJmRW.J7y40eYIoH_lJjL9stLT7qW390ZqY5D0frogJfpVT0fbunvvaIReGboUd0izKJE wqqUyHBe5brDwNnur.omT3sGiB7LXZfacntaJJAi8XlrFTibNM.5zQI3wdIjvh4WM.zyxG1zSsdX ItMuwpl13EqtZ4n1BWGwHMgmT6BXQ7BATwP8ZibUYdArtMD_kr581.mNS5aMcE1.2BjMQ9ah.rTo 2dDOtlS8D0z8XgdRvECzrGl_29nwXhwGX9dMN1sWwH3bYbKQijG4yA6vdA9tRZnGl4UaAkB480ra sBYfQekdoynE6_ZXwCC.U7T4Yy0L83SFRBpObzsVWF4ICqwbJL70_39Qkl6s90irQYy0WDQ5P4Ev IhMM874i3A9AOJLei7.2nryPZriDDpGiHZz2lD.DnvvIggc8D57JCTYrsS7A1yXqkOWCheJi59nn j4arzL5Tj3mDYqY8.PeohdAHoXERUQb4I.J.80zfpZlZadKPiiy.i0sy3POgGN4VMjiegH3rDO0m aMq_D_EKeyiaMILUp9FoYnFFbQURCvqotzvBxzZF0mO5BmMVVkZvidjVFTaqcYqEuhQDfZuyiDUW 5S3arsN3qb2owAYbWn8hx0Yx0PcJIOFwztQN3OHpnLCOmDbsq2wzLi76bnvXKePi854Yc1UUh_yo Ip_LDq76TWKLiZjFOhnPoT_PD_gjw2cYMKWWJSN1FVTrX3oYpfiL0yshpxeaugV8n7Xsb7q.hZhs .0VNxGrVqmPSXuyokeGpu2JycE7BRM75TX1vDWajBhHM9Pxf6Dd4cU7OTsq872tclbUMWQFVDh17 9WDzV3kxK5YCFJCJjB8GBB1E2c.sTXqo9rUbv7mNoUOyFs23x6aB1XiDJcJdyuVYeF49XX2pP1f. fVo3kpHjtTLoDBqj5xMFAau3t.Pc8bMve9y8kKhPXQXam6PbHLMkF28J4eJcsCYbOj11YnP6Yyrl MoqP.g2fKcUf1SMs7RZiW2GXAri3eZKWFNWDqYDrHDXIWp59fvG_jeI1EDHwA4hic6OmRIlUJ8lQ 3SOqIGYb1eZdf_apGJnCeSC9IsDK7ohYtI8zj5Yxl2zyfklhJfSg91EWkuJ81jxYnJndcbBFjhpX dqzEegjrQIpFDxgNhOjDsBRoRbuH_5VuHfvKw_50PVr4T6Wxjph6ciUJyi1MqE9a20LS2NSn545Z yDFYRKZDlvT5xJ95bgDYnJHwiDr3_WwbVkQVnWjbzrqWa8txeW_pfd4fPUMtSkRPZTTSBX6gU3le v9zkEsN62_.ilvMSciuN8lVg6mcI0JVQkbEUfiVKfPGbXK6S54i_kClA4_SV43SFxHyPUn.Vlind AAFakuIhJE.GJgUlMQq6Qd4V3m3VsKkwcU_xyStVYb0GuaT7uPZcD7s.O_fgKfbeODKRIIEYB7.s CQjIwepUuoMEWqAAsF87FNcKr_MBEE6TpM6JNCJP9eJGvEafvUWhG9_.hHUSJp4tbSLQ7XId4U39 nnzbxyMgHJ8dHDXbKgcSFlx3p63lCVkr7EywutGbRerZHwd3GRvvnwdm6gSXgZePzpPwnTFpqTUO qsd7S7IcigP4Nodyf.6rZe4AM0PJoHdqOwGCWB10YcSNV.GUUSWHvGhnc5ZlE95sPiS2NYlD5Wfi B0O.VR8cSzVZECPpvvRFYYxkYYRfFEmzb1h9py_FIe8IzaC4wDfP..FeQAFMcHGmD9mhVL12mtYe rvypLOH6QyXf_mb2kkTfRPcREas4PMoyEbUVUuEAFHzmo9lm04ZeSvDerlE_t.0tBD6crtyF9H9i Yn9cku4KB7ckJ6JfEC6C1Yjte8siN0jf3Fa6V_Y6wwxCJJkuT5LvINiNTeXPbOmM6wNlQuVw0f1w BLek- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Dec 2022 21:42:42 +0000 Received: by hermes--production-ne1-7b69748c4d-kwzvj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 02bdea0e3b1d6f54655dbe7fa386c183; Wed, 07 Dec 2022 21:42:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.200.110.1.12\)) Subject: A possibly unintended consequence of the kernel's alloc_bounce_zone implementation? Message-Id: <21DE5CB7-76DF-4FC9-8EE9-2FC0F216C72F@yahoo.com> Date: Wed, 7 Dec 2022 13:42:24 -0800 Cc: freebsd-arm To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <21DE5CB7-76DF-4FC9-8EE9-2FC0F216C72F.ref@yahoo.com> X-Spamd-Result: default: False [-2.43 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.931]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4NS9kD4S4Cz3vSB X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N I was doing some exploratory investigation of getting a "C0T" RPi4B that does not have the PCIe block wrapper logic messed up --in order to avoid much of the bounce zone usage that adds to the challenged memory/RAM-caching subsystem involved. I ended up noticing an odd property of the alloc_bounce_zone implementation when I tried to have a larger hw.busdma zone show up. (This was before trying to get beyond 4 GiBytes.) To simplify the description below, I use examples of extreme conditions that are simple to describe. A) Presume that the sequence of calls to alloc_bounce_zone never had an incompatible alignment. (dmat->lowaddr is the point here.) B) Concentrate on two ordering properties across the calls: B1) The various dmat->lowaddr arrive in a strictly decreasing order vs. B2) The various dmat->lowaddr arrive in increasing order (B1) will produce a hw.busdma zone for each distinct value of dmat->lowaddr . (B2) will produce one hw.busdma zone with the smallest dmat->lowaddr being used for all the bounce activity. (The smallest could potentially be rather small.) It turned out that the RPi4B basically had its smallest dmat->lowaddr in the 2nd alloc_bounce_zone call so all later alloc_bounce_zone calls used that zone. (The actual size was relevant to me only because of the investigation involved.) This wording is slightly simplified from the actual context but should be suggestive enough. (I changed ">=" to "==" for my investigative activity, making the results be more like (B1), but independent of dmat->lowaddr arrival order. The zone order ends up being a permutation of (B1)'s order.) Are there any consequence of (B1) vs. (B2) big enough to make the existing implementation somewhat of a problem? Since (B1) can happen anyway (so: is a valid result), should the order dependency of alloc_bounce_zone's behavior be removed to avoid (B2) type results? === Mark Millard marklmi at yahoo.com