-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
why do we need MAP_SHARED for h2o_buffer_reserve() #1585
Comments
The intent of using mktemps + fallocate + mmap is to create a file-backed buffer so that the maximum amount of space that can be used for buffering data would be constrained by the free space of the disk instead of the swap.
That would be possible assuming that the added pages will not be anonymous. Note also that if use of Anyways, buffering large amount of data is a secondary strategy and I do not think it is a good idea to spend effort on improving the performance. I would rather prefer working on adopting streaming request (see #1357) to handlers other than the proxy handler. |
streaming request handled by handler which do not need large buffers, right? |
In my opinion usage of shared or private mmap resource (even as a temporary upload placeholder) is a bad idea. $TMP or $TMPDIR location can be anything in user environment, can be HDD for instance.. it is just an extra step for an admin to remember. Not to mention concurrent uploads of large files would easily create memory pressure if $TMP is ramdisk mount. I very much like your suggestion and direction in getting streaming request work with non-proxy handlers. Looking forward and ready to test! |
https://github.com/h2o/h2o/blob/master/lib/common/memory.c#L272
are there any others process which will access it? if not , why not set
MAP_PRIVATE
also, can we use mremap(2) instead of mmap(2) and munmap(2) on platform which support mremap?
The text was updated successfully, but these errors were encountered: