[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN4PR0401MB3598470B14C754768A2D8F389B790@SN4PR0401MB3598.namprd04.prod.outlook.com>
Date: Wed, 22 Jul 2020 07:13:54 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>
CC: Song Liu <song@...nel.org>, Hans de Goede <hdegoede@...hat.com>,
Richard Weinberger <richard@....at>,
Minchan Kim <minchan@...nel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"dm-devel@...hat.com" <dm-devel@...hat.com>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"drbd-dev@...ts.linbit.com" <drbd-dev@...ts.linbit.com>,
"linux-raid@...r.kernel.org" <linux-raid@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>
Subject: Re: [PATCH 06/14] block: lift setting the readahead size into the
block layer
On 22/07/2020 08:27, Christoph Hellwig wrote:
> + q->backing_dev_info->ra_pages =
> + max(queue_io_opt(q) * 2 / PAGE_SIZE, VM_READAHEAD_PAGES);
Dumb question, wouldn't a '>> PAGE_SHIFT' be better instead of a potentially
costly division?
Or aren't we caring at all as it's a) not in the fast-path and b) compilers
can optimize it to a shift?
Powered by blists - more mailing lists