Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753696AbcKRPKB (ORCPT ); Fri, 18 Nov 2016 10:10:01 -0500 Received: from mail-it0-f52.google.com ([209.85.214.52]:35087 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752558AbcKRPJ6 (ORCPT ); Fri, 18 Nov 2016 10:09:58 -0500 Subject: Re: [PATCH v4] mm: don't cap request size based on read-ahead setting To: Hillf Danton , "'Andrew Morton'" , "'Johannes Weiner'" , linux-mm@kvack.org References: <007401d24160$cc2442c0$646cc840$@alibaba-inc.com> Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, "'Linus Torvalds'" From: Jens Axboe Message-ID: <6010891c-e4a2-e19b-9042-128670fd8fff@kernel.dk> Date: Fri, 18 Nov 2016 08:09:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <007401d24160$cc2442c0$646cc840$@alibaba-inc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1393 Lines: 30 On 11/17/2016 10:58 PM, Hillf Danton wrote: > On Friday, November 18, 2016 5:23 AM Jens Axboe wrote: >> >> We ran into a funky issue, where someone doing 256K buffered reads saw >> 128K requests at the device level. Turns out it is read-ahead capping >> the request size, since we use 128K as the default setting. This doesn't >> make a lot of sense - if someone is issuing 256K reads, they should see >> 256K reads, regardless of the read-ahead setting, if the underlying >> device can support a 256K read in a single command. >> >> To make matters more confusing, there's an odd interaction with the >> fadvise hint setting. If we tell the kernel we're doing sequential IO on >> this file descriptor, we can get twice the read-ahead size. But if we >> tell the kernel that we are doing random IO, hence disabling read-ahead, >> we do get nice 256K requests at the lower level. This is because >> ondemand and forced read-ahead behave differently, with the latter doing >> the right thing. > > As far as I read, forced RA is innocent but it is corrected below. > And with RA disabled, we should drop care of ondemand. > > I'm scratching. The changelog should have been updated. Forced read-ahead is also affected, the patch is correct. We want to use the min of 'nr_to_read' and the proper read-ahead request size, the latter being the max of ra->ra_pages and bdi->io_pages. -- Jens Axboe