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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 36410C77B61 for ; Mon, 27 Mar 2023 09:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8zQtY+qJ16v/tNu4a+f6TxA6WPlu6Jb3GjMLcgJiQ+4=; b=01P20ggMhdYBp7 IR3Oc9z+nz3El8RI3aUwzObDop7GSE/0vCRC1t187v9SxB9tiRFP0Ijl11tLOmht+ywinsRKmrtfY Fa8I9qnmVLSDlX42rklsmYaVGycOhrOzNbu5WZD4+OT/QU/M16Tvi6CvYL7lOsXoYYO5QbYdSApo3 Zc84+6KyZZpslZ25XVsfmA087kEm6mJxKaUqTJVvfUhJICvlKs7O6cMbo67okp7NEb9teb0a6QM2H pEW86drZpkZYaNLNMv0eOI8xG4VCabcYZiK+IWhg2WBbDrk1p2jNivskA65iFkRRbstP8xuGWAH1E eFj+lMA0dp6MCwN41kxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pgjFC-00AUQO-27; Mon, 27 Mar 2023 09:34:26 +0000 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pgjF7-00AUOe-29 for linux-arm-kernel@lists.infradead.org; Mon, 27 Mar 2023 09:34:23 +0000 Received: by mail-wr1-x434.google.com with SMTP id i9so8002165wrp.3 for ; Mon, 27 Mar 2023 02:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679909658; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=POgdeDq6GTq5hmNPSFdueivmMjzmCDTzevp+cgu6XvA=; b=mR7CT2fV0Ybfj2vBd13RThvEyQ1D/PFjh1kTPbdiiQnlgV/kM/CwdDqtXmhZ7zZGki nix0hpWmXn1G3Cd3Z54UOTdcdRCrOIPzMOGhvCFoJTB4r1v+/tLUM/1yVWUbrpsa3yHo LTBfnCK7l+x0J2n6XR0LXHrrMJMhpEaIAi70Z8L9NWOKjT/1kbUXLw2H79C4dG4qvWfU qi/mRpIwP1XhTzT0NcgAjFp1QAXMhVgwDTIOQ2QnTCl2iuDjYg6lAqg6UBp9TuPnEeXz dFALI1ZWsDOvy2loMU6WEcZPP79BHa2SzQ8aOabfFnaFBzpQmZxH8KgeV4xSxmcGzgMt vNrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679909658; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=POgdeDq6GTq5hmNPSFdueivmMjzmCDTzevp+cgu6XvA=; b=WQZKE5+ALdzHKkFIH07PfN4C3PmuP3gsqHBN+78U3fegDF5orw2Gu89NnDpeQbj08A Sk54+UMa/Q2PPB0R0/yDE0V/sDbIYsZcMNBD9qVR2hI25Vq4UpMMbmXAcNulqgNrB/zQ jLrqLkEX+ZREeZHzNuxu4eIw+7xzE5ihfnqfiuvGe949b5BRbs2vY0OmDuzh7rwilCq4 L5pszsxjEXqAt1qzTZo4apWtCKRS74L2sD4vCs346rFA0KnvQgh0HY0HXeFe4H6MT14m E37BAd7xvk8Uy3eO4sVr8pRPSXHxbpWOk7cF3+KhyaLolIqW/JeAGcM4SmotP1FYLfx3 URDw== X-Gm-Message-State: AAQBX9fst/8B/sq+ZIipliR00zgzGz3mp80m8GU197gj7IjmTZjNcWIc 8zmDZXKFKxpxnlUQKbHT8oAtLw== X-Google-Smtp-Source: AKy350biDzt4J5AlQf8bORqhDcPyA2F6kFQA73y6/+x397VtOTmTSjosx2Yg2EBrJbXnu7dsvNVQ3Q== X-Received: by 2002:a5d:414c:0:b0:2d6:4e98:5f32 with SMTP id c12-20020a5d414c000000b002d64e985f32mr8347150wrq.23.1679909657869; Mon, 27 Mar 2023 02:34:17 -0700 (PDT) Received: from [192.168.2.107] ([79.115.63.91]) by smtp.gmail.com with ESMTPSA id u8-20020adfdb88000000b002cff06039d7sm24536801wri.39.2023.03.27.02.34.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Mar 2023 02:34:17 -0700 (PDT) Message-ID: Date: Mon, 27 Mar 2023 10:34:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v4 0/8] mtd: spi-nor: read while write support Content-Language: en-US To: Miquel Raynal Cc: Richard Weinberger , Vignesh Raghavendra , Pratyush Yadav , Michael Walle , linux-mtd@lists.infradead.org, Julien Su , Jaime Liao , Jaime Liao , Alvin Zhou , Thomas Petazzoni , Michal Simek , linux-arm-kernel@lists.infradead.org References: <20230201113603.293758-1-miquel.raynal@bootlin.com> <20230324145140.58509d50@xps-13> From: Tudor Ambarus In-Reply-To: <20230324145140.58509d50@xps-13> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230327_023421_705438_996FAD57 X-CRM114-Status: GOOD ( 32.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On 3/24/23 13:51, Miquel Raynal wrote: > Hi Tudor, Hi! > > tudor.ambarus@linaro.org wrote on Fri, 17 Mar 2023 04:13:27 +0000: > >> On 2/1/23 11:35, Miquel Raynal wrote: >>> Hello folks, >>> >>> Here is the follow-up of the RFC trying to bring a little bit of >>> parallelism to support SPI-NOR Read While Write feature on parts >>> supporting it and featuring several banks. >>> >>> I have received some hardware to make it work, so since the RFC, the >>> series has been updated to fix my mistakes, but the overall idea is the >>> same. >>> >>> There is nothing Macronix specific in the implementation, the operations >>> and opcodes are exactly the same as before. The only difference being: >>> we may consider the chip usable when it is in the busy state during a >>> write or an erase. Any chip with an internal split allowing to perform >>> parallel operations might possibly leverage the benefits of this >>> implementation. >>> >>> The first patches are just refactoring and preparation work, there is >>> almost no functional change, it's just a way to prepare the introduction >>> of the new locking mechanism and hopefully provide the cleanest and >>> simplest diff possible for this new feature. The actual change is all >>> contained in "mtd: spi-nor: Enhance locking to support reads while >>> writes". The logic is described in the commit log and copy/pasted here >>> for clarity: >>> >>> " >>> On devices featuring several banks, the Read While Write (RWW) feature >>> is here to improve the overall performance when performing parallel >>> reads and writes at different locations (different banks). The >>> following constraints have to be taken into account: >>> 1#: A single operation can be performed in a given bank. >>> 2#: Only a single program or erase operation can happen on the entire >>> chip (common hardware limitation to limit costs) >>> 3#: Reads must remain serialized even though reads on different banks >>> might occur at the same time. >>> 4#: The I/O bus is unique and thus is the most constrained resource, >>> all spi-nor operations requiring access to the spi bus (through >>> the spi controller) must be serialized until the bus exchanges >>> are over. So we must ensure a single operation can be "sent" at >>> a time. >>> 5#: Any other operation that would not be either a read or a write or an >>> erase is considered requiring access to the full chip and cannot be >>> parallelized, we then need to ensure the full chip is in the idle >>> state when this occurs. >>> >>> All these constraints can easily be managed with a proper locking model: >>> 1#: Is enforced by a bitfield of the in-use banks, so that only a single >>> operation can happen in a specific bank at any time. >>> 2#: Is handled by the ongoing_pe boolean which is set before any write >>> or erase, and is released only at the very end of the >>> operation. This way, no other destructive operation on the chip can >>> start during this time frame. >>> 3#: An ongoing_rd boolean allows to track the ongoing reads, so that >>> only one can be performed at a time. >>> 4#: An ongoing_io boolean is introduced in order to capture and >>> serialize bus accessed. This is the one being released "sooner" >>> than before, because we only need to protect the chip against >>> other SPI accesses during the I/O phase, which for the >>> destructive operations is the beginning of the operation (when >>> we send the command cycles and possibly the data), while the >>> second part of the operation (the erase delay or the >>> programmation delay) is when we can do something else in another >>> bank. >>> 5#: Is handled by the three booleans presented above, if any of them is >>> set, the chip is not yet ready for the operation and must wait. >>> >>> All these internal variables are protected by the existing lock, so that >>> changes in this structure are atomic. The serialization is handled with >>> a wait queue." >>> >>> Here is now a benchmark with a Macronix MX25UW51245G with 4 banks and RWW >>> support: >>> >>> // Testing the two accesses in the same bank >>> $ flash_speed -b0 -k0 -c10 -d /dev/mtd0 >>> [...] >>> testing read while write latency >>> read while write took 51ms, read ended after 51ms >>> >>> // Testing the two accesses within different banks >>> $ flash_speed -b0 -k4096 -c10 -d /dev/mtd0 >>> [...] >>> testing read while write latency >>> read while write took 51ms, read ended after 20ms >>> >>> Parallel accesses have been validated with io_paral. A slight increase >>> of the time spent on this test has however been noticed. With my >> >> how do the other tests look? Is there any change in performance for >> flashes that do not support RWW? > > The current implementation takes care of not changing anything with the > existing flashes, when I resend I'll provide all the logs you asked yes, I saw. There are some ifs here and there, nothing scary, so I don't expect any change in performance for the flashes without RWW support, but it's always good to have a proof. > for, plus another quick test without the RWW feature bit set. > Cool, thanks! Cheers, ta _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel