From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752307AbdLMDFl (ORCPT ); Tue, 12 Dec 2017 22:05:41 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:44722 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752376AbdLMDFg (ORCPT ); Tue, 12 Dec 2017 22:05:36 -0500 Subject: Re: [PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED To: Tejun Heo Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org, oleg@redhat.com, peterz@infradead.org, kernel-team@fb.com, osandov@fb.com References: <20171209192525.982030-1-tj@kernel.org> <20171209192525.982030-7-tj@kernel.org> <8c52269a-d5a9-d13c-bdb6-8f47cdaed982@oracle.com> <20171212172629.GF3919388@devbig577.frc2.facebook.com> From: "jianchao.wang" Message-ID: <9e9452b1-5756-71fc-f7f9-2a90aceccf01@oracle.com> Date: Wed, 13 Dec 2017 11:05:11 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171212172629.GF3919388@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8743 signatures=668646 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712130040 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ｈｉ tejun On 12/13/2017 01:26 AM, Tejun Heo wrote: > Hello, again. > > Sorry, I missed part of your comment in the previous reply. > > On Tue, Dec 12, 2017 at 06:09:32PM +0800, jianchao.wang wrote: >>> static void __blk_mq_requeue_request(struct request *rq) >>> { >>> @@ -679,7 +672,7 @@ static void __blk_mq_requeue_request(struct request *rq) >>> wbt_requeue(q->rq_wb, &rq->issue_stat); >>> blk_mq_sched_requeue_request(rq); >>> >>> - if (test_and_clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags)) { >>> + if (blk_mq_rq_state(rq) != MQ_RQ_IDLE) { >>> blk_mq_rq_update_state(rq, MQ_RQ_IDLE); >> >> The MQ_RQ_IDLE looks confused here. It is not freed , but idled. >> And when the requeued request is started again, the generation >> number will be increased. But it is not a recycle instance of the >> request. Maybe another state needed here ? > > I don't quite follow it. At this point, the request can't be > in-flight on the device side and is scheduled for re-submission. I'm > not sure the distinction from IDLE is necessary. Am I missing > something? Just don't quite understand the strict definition of "generation" you said. A allocation->free cycle is a generation ? or a idle->in-flight cycle is a generation? The idle->in-flight cycle could include the requeue case as above. Can you clarify this? Thanks Jianchao > > Thanks. >