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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1977DC47258 for ; Thu, 25 Jan 2024 09:38:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A178A8D0016; Thu, 25 Jan 2024 04:38:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C76D8D0015; Thu, 25 Jan 2024 04:38:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 869C88D0016; Thu, 25 Jan 2024 04:38:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 713E68D0015 for ; Thu, 25 Jan 2024 04:38:04 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 43C491C17D3 for ; Thu, 25 Jan 2024 09:38:04 +0000 (UTC) X-FDA: 81717332088.03.9652526 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf08.hostedemail.com (Postfix) with ESMTP id 6BB9C16000E for ; Thu, 25 Jan 2024 09:38:02 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TwShbXtJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706175482; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=V+RkNqMrCMWSlr+Yh44U7hyKXYEqjphS14jY3zThSRg=; b=jqnPsVxnSVy5SXw9bOCdIK0NdGolSChefV8aPMKSa8zY9CNs9eVdzuIOqvTo7coU5k7rN/ nr6SiojdPBKmcrLSewIyiFgI4RozdvAf34PHFUWIzLdxNFuELHVMyOkeISJLAyZdVdeF46 PowOxAoE8Vg7WLI6foptBxDV8pfiWhc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TwShbXtJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706175482; a=rsa-sha256; cv=none; b=D51gL2FaTYXE+zTdR7NAhS5Yi/kRrSy+6FQz4BqdJE90oNDAKiNDLeS4yfFW0Z46HbGh7D pxHZ9jvA89Iee79p6zPxlf+PKU1J+rODEA3VPwJtflQVzrPpXbDDjkhIf4jAlefjpW0fP4 qhYAYMEWweCd5a0/NXKDf/B2dNL+f1A= Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2cf1b770833so26436221fa.0 for ; Thu, 25 Jan 2024 01:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706175480; x=1706780280; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V+RkNqMrCMWSlr+Yh44U7hyKXYEqjphS14jY3zThSRg=; b=TwShbXtJaVXa9REIn4Cu+g5TXrrj3VZ7ITol8XNKv2NsJqPldizmdSOM9V1arkG4lO AhIdyO0myhU+VFvF4pQi2Q1nEFnQ3dYYHhwjC7FMZ/YJeUmW+VANpoRCXJ40GrslJ7dO G2JUYBaIPiKxx6sRvcslJcfol7IxL3QkHTiJalQREo06DuuBLhrVbO0Zp34NaX3h4Z/s NttTl3jBTuRzsN9e71KLUQs1pq09L3Yc7E1NZRZflYwph9eGooEwUQLGiO1dO+idnYtO 2R9bhfJ59pzV0xKsvSPn0GZ+xgruw8Ntpvq3JEZQKkIxIp9guaeKNjo7/UtmsxBaXj3X zOeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706175480; x=1706780280; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V+RkNqMrCMWSlr+Yh44U7hyKXYEqjphS14jY3zThSRg=; b=Y33/mazkf/hwNcqPnXHVTL+1+kEIfRfviZWPofCLmGoVnbezzL6meVOWHzbbVisNdv A2CWWfVgB/iqcISZYJI0hdmktNGy7tbgMzNC+SR8dyWNww+d3PrZ7PivBu6kIfCDLe9t 9dY9OFzK+4x3myTRcDqstpzWKEYQdczKZNu1v69NC+S2BM450ti+Ksi2l5b842+7G1np blMlU/ww5qrMhZBwmM61GeuZteBkULPXdkOa+zpp6KfiOo9ukT7DqtRWNc5MTcCDubpM o0XV143QRy+JyQujzU9CXFiINmbGCX/Z3TI+eFnVQqX7HCqkuSbZD7yzn6g929JaUl4Z cBwA== X-Gm-Message-State: AOJu0YzkIIKVMRPR6Q3xVyPar7QbJxSLHZquG/ADpjrX2bxTIS/9z3lV +BUvWzd+ffKBHSiK0waW91fVEduPEjLVRECDwaBsqm9RcQhHel/MbhjkDeRjqCcV6mGAAgSjWKx n8SnJKQ1Vl1vteEDAJiW4ZhL+s30= X-Google-Smtp-Source: AGHT+IFQb9lHVoPdeNHadDfo2biHwzJySgJs7FG5T5F0tRJc/2lFbJsqxK/r3ISDkgkkVps3PuhohFcNDxKPVBnVh3o= X-Received: by 2002:a2e:81c3:0:b0:2ce:fbca:606a with SMTP id s3-20020a2e81c3000000b002cefbca606amr357473ljg.40.1706175480409; Thu, 25 Jan 2024 01:38:00 -0800 (PST) MIME-Version: 1.0 References: <20240125071901.3223188-1-zhaoyang.huang@unisoc.com> <6b2d5694-f802-43a4-a0fd-1c8e34f8e69a@kernel.org> <95082224-a61d-4f4b-bc96-1beea8aa93a9@kernel.org> In-Reply-To: From: Zhaoyang Huang Date: Thu, 25 Jan 2024 17:37:49 +0800 Message-ID: Subject: Re: [PATCHv3 1/1] block: introduce content activity based ioprio To: Damien Le Moal Cc: "zhaoyang.huang" , Andrew Morton , Jens Axboe , Yu Zhao , Niklas Cassel , "Martin K . Petersen" , Hannes Reinecke , Linus Walleij , linux-mm@kvack.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 6BB9C16000E X-Stat-Signature: efnbw6e6xrapuo39w9z6ec7n6dmmfzag X-Rspam-User: X-HE-Tag: 1706175482-429832 X-HE-Meta: U2FsdGVkX1/Ig/vWKTtzkD5bnaew+NJJLh54CD6RUgyAhU8Ky0ra1c/HbvqVAiPAEsnEQnEUpwGBy05f3rizyYYiqJugeX98Kh8Qo8mL9YFbHwqGukE51BMy5eHEJT2M+0AhJCaIEidmRWlxElCU9eCxfCfO/M7qLIH82e+S6IIAvyF0/HwTpceh4gQ8EJqI49NVeXknv+sJJ4V4oickGREn0FYkwpainkGoESZWLgvXO46b9srIR7H/hBJHgfeAVzaJAh8+btL30DYwctncD50oNQL9s8on4ccA1zv5IdspZSdQ1weBCJ8qFYDEMdx90t8h3JdZTl6qP6NmfWaR2MR88ctGdFayUE8MzjzIHrPmxQhknS+JL81HmojMgxQ5dt2Qrqigkt3UeHtWZ82LRouNJ9kwrk4IzwVm72QIJrnYfKJYuUx4OU/fKxEfItynw6MTrG5hFkj2SvOPIH5RunqGac8H9SjJHzwjv2O01IWhiNA0gSjQa1DVAIut1wZv8S6Xo6AfQhIa1SH4+gQBUHzuQUOPNqoPKcRygluv2A3Fv4sA+hxK23JWBCY4VCwqyrv0aA3D2LZCFkm+29/vORIg6XRu0BeDvlp7MoX9zX7/g4/9YGbByX9WurXaxZB0VQwQrBzJ6YH2gcKoqZDNfaYnSYFT4MOt4DN8TXviQKI6DNKtUYaYOsET8Sk+KaN5qgcPP4wbV70vFxB4h1YZcnLE+MVqeU75mX4D43yzKTFDKZKo+rK0Wpj21kAhuVaHTGZcmZBl32srGNmJQ4q+/Y6iMapKSdz5AZwwE/vyts57uHuK1a7gVP/+/CxjDD1lZObklk5IWzJXIcAEF13AUkVJ546BaKAh95cC4vJdYYLFQeDcf8i0weSOPUDT/62qqYlQUN42J1DumPu76IEe9pWjCiQ4G3iup8fqxECkPdXkXQiBEnEJyPLlshW71D47xn5bdTuINntbGxq8kae abw7CWzK /3C1IiAxDZ/8m8+hoxfOtlduaP3WWAJpugcZLlkuyLvqlt3vNgJ0NqBRFLxSJl9qUMWLhUGXysdGLw9LCmvXV0jOV81tkXsuj2LntMpFM5degz9dJ25rxBwtqidXSt9TDKGUaU/gwZ/R3yTPTEjsAj3cKCiCRk66lXGQJq8ciE7vmUNO9VEq9RladQPViXZfE67PQUPLq44gKxQY0aHj7CNrcbLmIsBnLRVWwRYxjjzk+9f1Hh6PmBvUfYNiNBRmGLPPGyLkzvtPifTn90DMYe+BmZgNmI+BUL1sc8OH2J7lgoKPfhhOyjiEI/8+oFJWn/72Cs01aHUJj5Zg0SSHxs3DBypWzuX4HJVCze1lH8ATPkHcd9Gm7yV4ewRIThtIjnyJ14W7GxFVC+Zp3R8iRm45Ph+TT+bh47ogkPNTXwufFSpeAUXkK7lmwW04f4T5MhON89IihuMTkZrJPULZxA8c7Z7tlNJgmCEhRyiPCg2B6uHzI1S3g4puaTg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 25, 2024 at 5:32=E2=80=AFPM Zhaoyang Huang wrote: > > On Thu, Jan 25, 2024 at 4:26=E2=80=AFPM Damien Le Moal wrote: > > > > On 1/25/24 16:52, Zhaoyang Huang wrote: > > > On Thu, Jan 25, 2024 at 3:40=E2=80=AFPM Damien Le Moal wrote: > > >> > > >> On 1/25/24 16:19, zhaoyang.huang wrote: > > >>> From: Zhaoyang Huang > > >>> > > >>> Currently, request's ioprio are set via task's schedule priority(wh= en no > > >>> blkcg configured), which has high priority tasks possess the privil= ege on > > >>> both of CPU and IO scheduling. > > >>> This commit works as a hint of original policy by promoting the req= uest ioprio > > >>> based on the page/folio's activity. The original idea comes from LR= U_GEN > > >>> which provides more precised folio activity than before. This commi= t try > > >>> to adjust the request's ioprio when certain part of its folios are = hot, > > >>> which indicate that this request carry important contents and need = be > > >>> scheduled ealier. > > >>> > > >>> This commit is verified on a v6.6 6GB RAM android14 system via 4 te= st cases > > >>> by changing the bio_add_page/folio API in ext4 and f2fs. > > >> > > >> And as mentioned already by Chrisoph and Jens, why don't you just si= mply set > > >> bio->bi_ioprio to the value you want before calling submit_bio() in = these file > > >> systems ? Why all the hacking of the priority code for that ? That i= s not > > >> justified at all. > > >> > > >> Furthermore, the activity things reduces the ioprio hint bits to the= bare > > >> minimum 3 bits necessary for command duration limits. Not great. But= if you > > >> simply set the prio class based on your activity algorithm, you do n= ot need to > > >> change all that. > > > That is because bio->io_prio changes during bio grows with adding > > > different activity pages in. I have to wrap these into an API which > > > has both of fs and block be transparent to the process. > > > > Pages are not added to BIOs on the fly. The FS does bio_add_page() or s= imilar > > (it can be a get user pages for direct IOs) and then calls bio_submit()= . Between > > these 2, you can set your IO priority according to how many pages you h= ave. > Please correct me if I am wrong. So you suggest iterating the > request->bios->bvecs(pages) before final submit_bio? Is it too costly > and introduces too many modifications on each fs. > > > > You can even likely do all of this based on the iocb (and use iocb->ki_= ioprio to > > set the prio), so before one starts allocating and setting up BIOs to p= rocess > > the user IO. > Actually, the activity information comes from page's history (recorded > at page cache's slot) instead of user space in step(1) and can be > associate with bio in step(2) or iterate the bio in step(3) > > page fault \ > (1) > (2) (3) > allocate_pages=3D=3D>add_page_to_page_cache(get > activity information)=3D=3D>xxx_readpage=3D=3D>bio_add_page=3D=3D>submit_= bio > vfs read/write / The chart goes wrong again:( change it to vertical mode Actually, the activity information comes from page's history (recorded at page cache's slot) instead of user space in step(1) and can be associate with bio in step(2) or iterate the bio in step(3) page fault(or vfs)(1) | alloc_pages | add_page_to_pagecache(get the page's activity information) | fs_readpage | bio_add_page(2) | submit_bio(3) > > > > -- > > Damien Le Moal > > Western Digital Research > >