> On 9 Jan 2017, at 17:29, Andreas Gerstmayr <andreas.gerstmayr@xxxxxxxxxxxx> wrote: > > Am 09.01.2017 um 02:54 schrieb Yan, Zheng: >> >>> On 8 Jan 2017, at 00:31, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: >>> >>> On Thu, Jan 5, 2017 at 4:23 PM, Andreas Gerstmayr >>> <andreas.gerstmayr@xxxxxxxxxxxx> wrote: >>>> This patch sets the io_pages bdi hint based on the rvsize mount option. >>>> Without this patch large buffered reads (request size > max readahead) >>>> are processed sequentially in chunks of the readahead size (i.e. read >>>> requests are sent out up to the readahead size, then the >>>> do_generic_file_read() function waits until the first page is received). >>>> >>>> With this patch read requests are sent out up to the size specified in >>>> the new rvsize mount option at once (default: 64 MB). >>>> >>>> Signed-off-by: Andreas Gerstmayr <andreas.gerstmayr@xxxxxxxxxxxx> >>>> --- >>>> >>>> Thanks for your review. >>>> On second thought, I think I should not reuse the rsize mount option >>>> (maximum read size per OSD request), therefore I created a new mount >>>> option rvsize with a default value of 64 MB (as you suggested). >>>> >>>> (Note: This patch depends on kernel version 4.10-rc1) >>> >>> I'll defer to Zheng's judgement, but a separate mount option for this >>> seems overkill to me. We should be able to work something out between >>> the existing rsize and rasize. >> >> I agree with Ilya. I think we can user rsize here. > > But then we are using a single config option for two different purposes? > - to specify the maximum size of a single read request to an OSD > - to specify the maximum cumulative size of read requests sent out at > once limit max size of single request does not make much sense. The only case I can think of is system has limited memory. For that case, it does not make sense to send parallel requests. Regards Yan, Zheng > > In general the latter will be a multiple of the former. > > > Regards, > Andreas -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
