From patchwork Thu Aug 24 18:09:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 9920657 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 94A7360349 for ; Thu, 24 Aug 2017 18:09:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 845D028C0A for ; Thu, 24 Aug 2017 18:09:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 793A728C0F; Thu, 24 Aug 2017 18:09:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6808D28C36 for ; Thu, 24 Aug 2017 18:09:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753556AbdHXSJi (ORCPT ); Thu, 24 Aug 2017 14:09:38 -0400 Received: from mail-pg0-f48.google.com ([74.125.83.48]:33455 "EHLO mail-pg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753519AbdHXSJc (ORCPT ); Thu, 24 Aug 2017 14:09:32 -0400 Received: by mail-pg0-f48.google.com with SMTP id t3so1302150pgt.0 for ; Thu, 24 Aug 2017 11:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=8YlCjh0zePUAu0sMzfEMdebz0hejrNC8bnFKsmayh0Y=; b=S0xyEzmC2e+YovPgB1PE7v7aRAffBqlqoSVzOkzo6+jqMsp9uNoqD2YEvmGeM55bOL l3wF6o+4juK4IeHLrs2vB4s/fME8KPbpbQ7mtEUK7vJB5EfovLHyl1gQyEk5uZq/a0Wr XUs4Or56pIeAPAXNLE9b1evbBOSTfVv7zZ/aIkkICYpzRiBoM7qLdbMv/2LGXe5UpIkW ok1dLESVvewxCog3AoACc4FrXU8fo/3PH9JjaPm0NBxzueo9OBeAOObDG1wWDTh/oFb/ MNGjOZN2DLR6ZYXw2J9VK5iejY/uaVKzdn38+1lXM8KRuTVdbtNX7rMeuxnRYs9Csp17 WjLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=8YlCjh0zePUAu0sMzfEMdebz0hejrNC8bnFKsmayh0Y=; b=n+JGjzq6IY7gIUPUD/l9aG32ojlF1VFy9hJg9NoYX2DSkMjSkFiAFeLuWsJ9Jk/pJo ednoOurrrcI3fPqoHNxxdSxbBVSVPGB6t0jmJM/N7pLGHSRewziqKVhUIF6GIj4Fljap bzEquTlPiksW6N0dhSP07Slp5pJ4N+foMf8Xjkr1XM8V+6RvO+lLegMtZb4bdhmMGi+o AQUF9+5so+JSUQUDECUSBtxQgJu9QYCoVmnXASZFi7DFgfKAbccdQpW1hmSuLzveJgm+ rKaDc6hamx8umRcI+BT1VWWzhBfHn4OqWfh69NvAtL2kDpRs8malOI+FDZBq0T4sj+S3 hH6w== X-Gm-Message-State: AHYfb5it8bdZlQqx5Dxbt6KCbtDJB933Z4rxs/M7/HbB5O8iD3dBAT5/ zms5PZUIukpeahOqS/wXog== X-Received: by 10.98.163.69 with SMTP id s66mr7203909pfe.167.1503598171465; Thu, 24 Aug 2017 11:09:31 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::7:72f7]) by smtp.gmail.com with ESMTPSA id o18sm9800171pgd.51.2017.08.24.11.09.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 11:09:30 -0700 (PDT) From: Omar Sandoval To: linux-block@vger.kernel.org Cc: kernel-team@fb.com Subject: [PATCH] block: update comments to reflect REQ_FLUSH -> REQ_PREFLUSH rename Date: Thu, 24 Aug 2017 11:09:25 -0700 Message-Id: <4c5c12f867eaf4da2230e11cfb27676e29c152e1.1503598124.git.osandov@fb.com> X-Mailer: git-send-email 2.14.1 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Omar Sandoval Normally I wouldn't bother with this, but in my opinion the comments are the most important part of this whole file since without them no one would have any clue how this insanity works. Signed-off-by: Omar Sandoval --- Based on Jens' for-next branch, for 4.14. block/blk-flush.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/block/blk-flush.c b/block/blk-flush.c index ed5fe322abba..3e77676244d9 100644 --- a/block/blk-flush.c +++ b/block/blk-flush.c @@ -1,12 +1,12 @@ /* - * Functions to sequence FLUSH and FUA writes. + * Functions to sequence PREFLUSH and FUA writes. * * Copyright (C) 2011 Max Planck Institute for Gravitational Physics * Copyright (C) 2011 Tejun Heo * * This file is released under the GPLv2. * - * REQ_{FLUSH|FUA} requests are decomposed to sequences consisted of three + * REQ_{PREFLUSH|FUA} requests are decomposed to sequences consisted of three * optional steps - PREFLUSH, DATA and POSTFLUSH - according to the request * properties and hardware capability. * @@ -16,9 +16,9 @@ * REQ_FUA means that the data must be on non-volatile media on request * completion. * - * If the device doesn't have writeback cache, FLUSH and FUA don't make any - * difference. The requests are either completed immediately if there's no - * data or executed as normal requests otherwise. + * If the device doesn't have writeback cache, PREFLUSH and FUA don't make any + * difference. The requests are either completed immediately if there's no data + * or executed as normal requests otherwise. * * If the device has writeback cache and supports FUA, REQ_PREFLUSH is * translated to PREFLUSH but REQ_FUA is passed down directly with DATA. @@ -31,7 +31,7 @@ * fq->flush_queue[fq->flush_pending_idx]. Once certain criteria are met, a * REQ_OP_FLUSH is issued and the pending_idx is toggled. When the flush * completes, all the requests which were pending are proceeded to the next - * step. This allows arbitrary merging of different types of FLUSH/FUA + * step. This allows arbitrary merging of different types of PREFLUSH/FUA * requests. * * Currently, the following conditions are used to determine when to issue @@ -47,19 +47,19 @@ * C3. The second condition is ignored if there is a request which has * waited longer than FLUSH_PENDING_TIMEOUT. This is to avoid * starvation in the unlikely case where there are continuous stream of - * FUA (without FLUSH) requests. + * FUA (without PREFLUSH) requests. * * For devices which support FUA, it isn't clear whether C2 (and thus C3) * is beneficial. * - * Note that a sequenced FLUSH/FUA request with DATA is completed twice. + * Note that a sequenced PREFLUSH/FUA request with DATA is completed twice. * Once while executing DATA and again after the whole sequence is * complete. The first completion updates the contained bio but doesn't * finish it so that the bio submitter is notified only after the whole * sequence is complete. This is implemented by testing RQF_FLUSH_SEQ in * req_bio_endio(). * - * The above peculiarity requires that each FLUSH/FUA request has only one + * The above peculiarity requires that each PREFLUSH/FUA request has only one * bio attached to it, which is guaranteed as they aren't allowed to be * merged in the usual way. */ @@ -76,7 +76,7 @@ #include "blk-mq-tag.h" #include "blk-mq-sched.h" -/* FLUSH/FUA sequences */ +/* PREFLUSH/FUA sequences */ enum { REQ_FSEQ_PREFLUSH = (1 << 0), /* pre-flushing in progress */ REQ_FSEQ_DATA = (1 << 1), /* data write in progress */ @@ -148,7 +148,7 @@ static bool blk_flush_queue_rq(struct request *rq, bool add_front) /** * blk_flush_complete_seq - complete flush sequence - * @rq: FLUSH/FUA request being sequenced + * @rq: PREFLUSH/FUA request being sequenced * @fq: flush queue * @seq: sequences to complete (mask of %REQ_FSEQ_*, can be zero) * @error: whether an error occurred @@ -406,7 +406,7 @@ static void mq_flush_data_end_io(struct request *rq, blk_status_t error) } /** - * blk_insert_flush - insert a new FLUSH/FUA request + * blk_insert_flush - insert a new PREFLUSH/FUA request * @rq: request to insert * * To be called from __elv_add_request() for %ELEVATOR_INSERT_FLUSH insertions.