From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Rob Landley <rob@landley.net>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, yrl.pp-manager.tt@hitachi.com
Subject: Re: [RFC PATCH 5/5] fuse: add documentation of sysfs parameter to limit maximum fuse request size
Date: Thu, 12 Jul 2012 22:13:19 +0900 [thread overview]
Message-ID: <4FFECD6F.5070308@hitachi.com> (raw)
In-Reply-To: <4FF6DFFE.10203@landley.net>
Hi Rob,
Thank you for your comments.
(2012/07/06 21:54), Rob Landley wrote:
> On 07/05/2012 05:51 AM, Mitsuo Hayasaka wrote:
>> Add an explantion about the sysfs parameter to the limit
>> maximum read/write request size.
>>
>> Signed-off-by: Mitsuo Hayasaka<mitsuo.hayasaka.hu@hitachi.com>
>> Cc: Rob Landley<rob@landley.net>
>> Cc: Miklos Szeredi<miklos@szeredi.hu>
>> ---
>>
>> Documentation/filesystems/fuse.txt | 17 ++++++++++++++++-
>> 1 files changed, 16 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/filesystems/fuse.txt b/Documentation/filesystems/fuse.txt
>> index 13af4a4..e6ffba3 100644
>> --- a/Documentation/filesystems/fuse.txt
>> +++ b/Documentation/filesystems/fuse.txt
>> @@ -108,13 +108,28 @@ Mount options
>>
>> With this option the maximum size of read operations can be set.
>> The default is infinite. Note that the size of read requests is
>> - limited anyway to 32 pages (which is 128kbyte on i386).
>> + limited to 32 pages (which is 128kbyte on i386) if direct_io
>> + option is not specified. When direct_io option is specified,
>> + the request size is limited to max_pages_per_req sysfs parameter.
>
> "Note that the maximum size of read requests defaults to 32 pages (128k
> on i386), use max_pages_per_req to change this default."
>
> And then describe max_page_per_req sufficiently thoroughly below, all in
> one place.
OK, I will revise it.
>
> (By the way, has anybody actually tested it with a single page as the
> limit? Does that work?)
This patch series enables the maximum request size to change to arbitrary
number from 32 to 256, and cannot set it to less than 32 pages.
>
>> 'blksize=N'
>>
>> Set the block size for the filesystem. The default is 512. This
>> option is only valid for 'fuseblk' type mounts.
>>
>> +Sysfs parameter
>> +~~~~~~~~~~~~~~~
>> +
>> +The sysfs parameter max_pages_per_req limits the maximum page size per
>> +FUSE request.
>
> No, it limits the maximum size of a data request and the units are
> decimal number of pages. It doesn't change the size of memory pages in
> the system.
You are right. I will revise it.
>
> Also, your first hunk implies this setting only takes effect if they
> mounted with "-o direct_io", is that true?
The request size increases using max_pages_per_req for read operation w/
direct_io, and write operation w/ and w/o direct_io. But it is not changed
for read operation w/o direct_io. So, it is true if only focusing on read
operation.
>
>> + /sys/fs/fuse/max_pages_per_req
>> +
>> +The default is 32 pages. It can be changed from 32 to 256 pages, which
>> +may improve the read/write throughput optimizing it. This change is
>> +effective per mount. Therefore, the re-mounting of FUSE filesystem
>> +is required after changing it.
>
> I'd say "Changing it to 256 pages may improve read/write throguhput on
> systems with enough memory. Existing FUSE mounts must be remounted for
> this change to take effect."
>
> I.E. don't imply 32 and 256 are the only options unless they are. (Is
> there some requirement that it be a power of 2, or just a good idea?)
Here, I wanted to imply that the max_paegs_per_req can be changed to
arbitrary number from 32 to 256. I will revise it since this explanation
is misleading.
Also, there is no requirement that it be a power of 2 although it is a
good idea if only focusing on kmalloc(). One of the reasons to introduce
the max_pages_per_req sysfs parameter is to let the libfuse get the
current maximum request size and change the MIN_BUFSIZE limitation
according to it to avoid an waste of memory in userspace.
>
> And per-mount sounds like you're setting it for a specific mount point,
> so if I have three mounts there would be three entries under
> /sys/fs/fuse, which does not seem to be the case. (Which is odd, because
> you'd think there would be an "-o max_pages_per_req=128" that _would_
> set this per-mount if the value actually used is cached in the
> superblock, but I'm not seeing one...)
The max_pages_per_req is a system limitation controlled by the administrator.
The actual number of allocated pages per request can be changed using
max_read/max_write mount options below this system limitation.
I will revise and resubmit this patch series soon.
Thanks,
>
> Rob
next prev parent reply other threads:[~2012-07-12 13:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-05 10:50 [RFC PATCH 0/5] fuse: make maximum read/write request size tunable Mitsuo Hayasaka
2012-07-05 10:50 ` [RFC PATCH 1/5] " Mitsuo Hayasaka
2012-07-05 10:50 ` [RFC PATCH 2/5] fuse: do not create cache for fuse request allocation Mitsuo Hayasaka
2012-07-05 10:51 ` [RFC PATCH 3/5] fuse: make default global limit minimum value Mitsuo Hayasaka
2012-07-05 10:51 ` [RFC PATCH 4/5] fuse: add a sysfs parameter to control maximum request size Mitsuo Hayasaka
2012-07-05 10:51 ` [RFC PATCH 5/5] fuse: add documentation of sysfs parameter to limit maximum fuse " Mitsuo Hayasaka
2012-07-06 12:54 ` Rob Landley
2012-07-12 13:13 ` HAYASAKA Mitsuo [this message]
2012-07-05 13:04 ` [RFC PATCH 0/5] fuse: make maximum read/write request size tunable Nikolaus Rath
2012-07-06 10:09 ` HAYASAKA Mitsuo
2012-07-06 5:53 ` Liu Yuan
2012-07-06 13:58 ` [fuse-devel] " Han-Wen Nienhuys
2012-07-12 5:58 ` HAYASAKA Mitsuo
2012-07-12 6:13 ` Liu Yuan
2012-07-12 10:13 ` Miklos Szeredi
2012-07-13 7:30 ` HAYASAKA Mitsuo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FFECD6F.5070308@hitachi.com \
--to=mitsuo.hayasaka.hu@hitachi.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rob@landley.net \
--cc=yrl.pp-manager.tt@hitachi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome