Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp6835916imm; Wed, 27 Jun 2018 14:24:43 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIkvw7+79xlPBki/mJAKquTrhyaoduIv9BY+9QOINRCJZE/4n170axZuXCbXFJMcdfppLuV X-Received: by 2002:a17:902:294a:: with SMTP id g68-v6mr7941694plb.58.1530134682977; Wed, 27 Jun 2018 14:24:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530134682; cv=none; d=google.com; s=arc-20160816; b=wBPHpCzqDYsnPxWec3T5/4rZkTKK3gQgYTVKU4FCyjcayMKArnLrpVAofd8QC39q8v cgjKQb0fTVMMLx6g6F3gVvY3mXIan8n1hYXpZfDPORB8j0Jv6u9Dq2ilqioSbMItjstU +hE++8/QaaaMqO1mUB4fRAdEP8ibWFbEzwCDkYGiRZszeSfW6ICI5hpA8kBi04yZMyPX tQKj+qKKX56rsM+e7T63Vdb8l3P1nt2ZYKZbZXf88d7yiIq7O0CUKLmfmAiLv858jmLY swljfAbs+8225Gxx9PBlyHaQzdoTXkDF9CZQsX+TMQCnbgs3TD0kSfNMn9nEnKGbtXcK OK5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=M0vNw8hmsAb6woA7xPJKQ//mSQledytLWdurKhmDrhs=; b=SlNSRtbEpzYzEEpdNey6043kLhFiEiuUp5CxAkA95EMThrGeA6A2CduZYoP1vgZzlT G4hBy6dDEB+IFuIhrTANFbxNVhcCtAYiGCr4LPbRMS4xgFxncepKbDO4pIOQQ69odYoE XSAWOOZL2ZmN3cbjliWwPa0Gm0WLFbAKDi3AcTlYGkad58+YFpSsXlh4mairWwwDv0VI Wl5tCZQwI8HW0hKvFOmarcBHE9LNlaFt1MNw9kaRW0TOqrSIzigfD5ffDY8IG3HtYc5P vziXNKCd3YPc0WAxQvH1IkgR+Jn/pN1I9GdrJtaoQuyTrZi6uho8T9bQMyrnpELLGaYY Y9bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b="et/GJTr1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x127-v6si4297764pgb.618.2018.06.27.14.23.58; Wed, 27 Jun 2018 14:24:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b="et/GJTr1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966125AbeF0TGj (ORCPT + 99 others); Wed, 27 Jun 2018 15:06:39 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:52267 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966048AbeF0TGf (ORCPT ); Wed, 27 Jun 2018 15:06:35 -0400 Received: by mail-it0-f66.google.com with SMTP id p4-v6so1703987itf.2 for ; Wed, 27 Jun 2018 12:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M0vNw8hmsAb6woA7xPJKQ//mSQledytLWdurKhmDrhs=; b=et/GJTr1OakugLIieB/apoJiCY/9+S1+biKxT2o6yW/VtQxnIhjgXJlJDYs5YYFJIw 3B2f/bU0g7cIyLSLIDHnKDo5lpCoSjJ/qjQbbmIVMOhaYFscp3NcvpXww8r3fh8YhOmI wvppK28hgyeMhziCvGP/tDS4mTd77HD/SFQogs0AU/HQ8Jv5s28YwYtpfBYzcHphNJKq VumED3RFye2/vkhDaU0Xjmtmc349TDVtX11VENeMLxMDL4L0NivkNoX7lfuc1AyU/6c4 QzxgLLgoGqF+Tzc2zU8Y0TkQfTprEJXPgznYHLpifmol8O4pCWcolkvnw1DNv56ztxrK YoEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M0vNw8hmsAb6woA7xPJKQ//mSQledytLWdurKhmDrhs=; b=nW9y6RjzMxhYBuy2ItIdrrTQ9DpnDfeO7IkQ6hCwXaihdpymqoQ6Pyemt9zaUxZ3PB F8hv891IDbskyNtkcliTqQboqBoUtsUc4AgktwjNLDJLQqd5rV3uqFiZSZGvBEFZsG2G WWklq7lNxQgOj47t0egEbQPzTm02YI19uEfQ5kukyK5Bp0b89522ckz6jxMbARSkD1wv WWHjaHHkZjf5GM7nl5/t6CdXTH7XDkWUrIDG4CWSE1GWpiP3Fd1pK10Ci58FXhbsCkIT YvUoOVmIeXu3lUMynMHFCNk0Ptm9dKqJ0LoP69WB1pjhZO4dTpdYXCWG0pLuFffH7xPX mKaA== X-Gm-Message-State: APt69E1qMTEupFEymqw0yd1lxNu/X29kTejHeywM9bY5dq6KpMQY8tbr tG2Hso68cffKoS8spDrRcr45JYuNMKs= X-Received: by 2002:a24:4fd3:: with SMTP id c202-v6mr5912206itb.32.1530126394634; Wed, 27 Jun 2018 12:06:34 -0700 (PDT) Received: from [192.168.1.212] (107.191.0.158.static.utbb.net. [107.191.0.158]) by smtp.gmail.com with ESMTPSA id l13-v6sm2155355iob.82.2018.06.27.12.06.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 12:06:33 -0700 (PDT) Subject: Re: [PATCH 12/15] block: introduce blk-iolatency io controller To: Josef Bacik , linux-block@vger.kernel.org, kernel-team@fb.com, akpm@linux-foundation.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, tj@kernel.org, linux-fsdevel@vger.kernel.org Cc: Josef Bacik References: <20180625151243.2132-1-josef@toxicpanda.com> <20180625151243.2132-13-josef@toxicpanda.com> From: Jens Axboe Message-ID: <05a581ed-8f21-9d89-a813-a03d802d3469@kernel.dk> Date: Wed, 27 Jun 2018 13:06:31 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180625151243.2132-13-josef@toxicpanda.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/25/18 9:12 AM, Josef Bacik wrote: > +static void __blkcg_iolatency_throttle(struct rq_qos *rqos, > + struct iolatency_grp *iolat, > + spinlock_t *lock, bool issue_as_root, > + bool use_memdelay) > + __releases(lock) > + __acquires(lock) > +{ > + struct rq_wait *rqw = &iolat->rq_wait; > + unsigned use_delay = atomic_read(&lat_to_blkg(iolat)->use_delay); > + DEFINE_WAIT(wait); > + bool first_block = true; > + > + if (use_delay) > + blkcg_schedule_throttle(rqos->q, use_memdelay); > + > + /* > + * To avoid priority inversions we want to just take a slot if we are > + * issuing as root. If we're being killed off there's no point in > + * delaying things, we may have been killed by OOM so throttling may > + * make recovery take even longer, so just let the IO's through so the > + * task can go away. > + */ > + if (issue_as_root || fatal_signal_pending(current)) { > + atomic_inc(&rqw->inflight); > + return; > + } > + > + if (iolatency_may_queue(iolat, &wait, first_block)) > + return; > + > + do { > + prepare_to_wait_exclusive(&rqw->wait, &wait, > + TASK_UNINTERRUPTIBLE); > + > + iolatency_may_queue(iolat, &wait, first_block); > + first_block = false; > + > + if (lock) { > + spin_unlock_irq(lock); > + io_schedule(); > + spin_lock_irq(lock); > + } else { > + io_schedule(); > + } > + } while (1); So how does this wait loop ever exit? -- Jens Axboe