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] [thread-next>] [day] [month] [year] [list]
Message-ID: <878vep478e.fsf@tucsk.pomaz.szeredi.hu>
Date:	Thu, 12 Jul 2012 12:13:53 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	HAYASAKA Mitsuo <mitsuo.hayasaka.hu@...achi.com>
Cc:	hanwen@...all.nl, Han-Wen Nienhuys <hanwenn@...il.com>,
	Liu Yuan <namei.unix@...il.com>,
	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

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?

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).

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ