linux-kernel - Re: [fuse-devel] [RFC PATCH 0/5] fuse: make maximum read/write request size tunable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 13 Jul 2012 16:30:07 +0900
From:	HAYASAKA Mitsuo <mitsuo.hayasaka.hu@...achi.com>
To:	Miklos Szeredi <miklos@...redi.hu>, hanwen@...all.nl,
	Han-Wen Nienhuys <hanwenn@...il.com>,
	Liu Yuan <namei.unix@...il.com>
Cc:	fuse-devel@...ts.sourceforge.net, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, yrl.pp-manager.tt@...achi.com
Subject: Re: [fuse-devel] [RFC PATCH 0/5] fuse: make maximum read/write request
 size tunable

Hi Miklos,

Thank you for your comments.

(2012/07/12 19:13), Miklos Szeredi wrote:
> HAYASAKA Mitsuo<mitsuo.hayasaka.hu@...achi.com>  writes:
>
>> Hi Yuan and Han-Wen,
>>
>> Thank you for your comments.
>>
>> (2012/07/06 22:58), Han-Wen Nienhuys wrote:
>>> On Fri, Jul 6, 2012 at 2:53 AM, Liu Yuan<namei.unix@...il.com>   wrote:
>>>> On 07/05/2012 06:50 PM, Mitsuo Hayasaka wrote:
>>>>> One of the ways to solve this is to make them tunable.
>>>>> In this series, the new sysfs parameter max_pages_per_req is introduced.
>>>>> It limits the maximum read/write size in fuse request and it can be
>>>>> changed from 32 to 256 pages in current implementations. When the
>>>>> max_read/max_write mount option is specified, FUSE request size is set
>>>>> per mount. (The size is rounded-up to page size and limited up to
>>>>> max_pages_per_req.)
>>>>
>>>> Why maxim 256 pages? If we are here, we can go further: most of object
>>>> storage system has object size of multiple to dozens of megabytes. So I
>>>> think probably 1M is too small. Our distribution storage system has 4M
>>>> per object, so I think at least maxim size could be bigger than 4M.
>>>
>>> The maximum pipe size on my system is 1M, so if you go beyond that,
>>> splicing from the FD won't work.
>>>
>>> Also, the userspace client must reserve a buffer this size so it can
>>> receive a write, which is a waste since most requests are much
>>> smaller.
>>>
>>
>> I checked the maximum pipe size can be changed using fcntl(2) or
>> /proc/sys/fs/pipe-max-size. It is clear that it is not a fixed value.
>>
>> Also, it seems that there is a request for setting the maximum number
>> of pages per fuse request to 4M (1024 pages). One of the reasons to
>> introduce the sysfs max_pages_per_req parameter is to set a threshold
>> of the maximum number of pages dynamically according to the
>> administrator's demand, and root can only change it.
>>
>> So, when the maximum value is required to be set to not more than the
>> pipe-max-size, the max_pages_per_req should be changed considering it.
>> It seems that the upper limit of this parameter does not have to be
>> not more than it.
>>
>> I'm planning to limit max_pages_per_req up to 1024 pages and add the
>> document to /Documentation/filesystems/fuse.txt, as follows.
>>
>> "the sysfs max_pages_per_req parameter can be changed from 32 to 1024.
>> The default is 32 pages. Generally, the pipe-max-size is 1M (256 pages)
>> and it is better to set it to not more than the pipe-max-size."
>
> Can't we just use pipe-max-size for the limit?

This is great!
I'd like to change this patch to using the pipe-max-size for the upper
limit of the max_pages_per_req sysfs paramter, and resubmit it.

>
> Then we'll use the minimum of pipe-max-size and max_read/max_write for
> sizing the requests.
>
> Another comment: do we really need to allocate each and every request
> with space for the pages?  I don't think that makes sense.  Let's leave
> some small number of pages inline in the request and allocate a separate
> array if the number of pages is too large.  There may even be some utilities
> in the kernel to handle dynamically sized page arrays (I haven't looked
> but I suspect there is).

This is interesting and enables to dramatically reduce the number of page
allocation and free. However, it seems that it is necessary to investigate
if this is feasible.

Thanks,

>
> Thanks,
> Miklos
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/