On 6/20/17 4:35 PM, Prakash Sangappa wrote:
On 6/16/17 6:15 AM, Andrea Arcangeli wrote:
Adding a single if (ctx->feature & UFFD_FEATURE_SIGBUS) goto out,
branch for this corner case to handle_userfault() isn't great and the
hugetlbfs mount option is absolutely zero cost to the handle_userfau
On 6/16/17 6:15 AM, Andrea Arcangeli wrote:
Hello Prakash,
Thanks for you response. Comments inline.
On Tue, May 09, 2017 at 01:59:34PM -0700, Prakash Sangappa wrote:
On 5/9/17 1:58 AM, Christoph Hellwig wrote:
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
Regardin
Hello Prakash,
On Tue, May 09, 2017 at 01:59:34PM -0700, Prakash Sangappa wrote:
>
>
> On 5/9/17 1:58 AM, Christoph Hellwig wrote:
> > On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
> >> Regarding #3 as a general feature, do we want to
> >> consider this and the complexity ass
On 5/9/17 1:59 PM, Prakash Sangappa wrote:
On 5/9/17 1:58 AM, Christoph Hellwig wrote:
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
Regarding #3 as a general feature, do we want to
consider this and the complexity associated with the
implementation?
We have to. Given
On 5/9/17 1:58 AM, Christoph Hellwig wrote:
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
Regarding #3 as a general feature, do we want to
consider this and the complexity associated with the
implementation?
We have to. Given that no one has exclusive access to hugetlbfs
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
> Regarding #3 as a general feature, do we want to
> consider this and the complexity associated with the
> implementation?
We have to. Given that no one has exclusive access to hugetlbfs
a mount option is fundamentally the wrong i
On 05/08/2017 08:58 AM, Dave Hansen wrote:
It depends on how you define the feature. I think you have three choices:
1. "Error" on page fault. Require all access to be pre-faulted.
2. Allow faults, but "Error" if page cache has to be allocated
3. Allow faults and page cache allocations, but
On 05/03/2017 12:02 PM, Prakash Sangappa wrote:
>>> If we do consider a new madvise()option, will it be acceptable
>>> since this will be specifically for hugetlbfs file mappings?
>> Ideally, it would be something that is *not* specifically for
>> hugetlbfs. MADV_NOAUTOFILL, for instance, could be
On 5/3/17 12:02 PM, Prakash Sangappa wrote:
On 5/2/17 4:43 PM, Dave Hansen wrote:
Ideally, it would be something that is *not* specifically for hugetlbfs.
MADV_NOAUTOFILL, for instance, could be defined to SIGSEGV whenever
memory is touched that was not populated with MADV_WILLNEED, mlock()
On 5/2/17 4:43 PM, Dave Hansen wrote:
On 05/02/2017 04:34 PM, Prakash Sangappa wrote:
Similarly, a madvise() option also requires additional system call by every
process mapping the file, this is considered a overhead for the database.
How long-lived are these processes? For a database, I'd a
On 05/02/2017 04:34 PM, Prakash Sangappa wrote:
> Similarly, a madvise() option also requires additional system call by every
> process mapping the file, this is considered a overhead for the database.
How long-lived are these processes? For a database, I'd assume that
this would happen a single
On 5/2/17 2:32 PM, Dave Hansen wrote:
On 05/01/2017 11:00 AM, Prakash Sangappa wrote:
This patch adds a new hugetlbfs mount option 'noautofill', to indicate that
pages should not be allocated at page fault time when accessed thru mmapped
address.
I think the main argument against doing someth
On 05/01/2017 11:00 AM, Prakash Sangappa wrote:
> This patch adds a new hugetlbfs mount option 'noautofill', to indicate that
> pages should not be allocated at page fault time when accessed thru mmapped
> address.
I think the main argument against doing something like this is further
specializing
On 5/2/17 3:53 AM, Anshuman Khandual wrote:
On 05/01/2017 11:30 PM, Prakash Sangappa wrote:
Some applications like a database use hugetblfs for performance
reasons. Files on hugetlbfs filesystem are created and huge pages
allocated using fallocate() API. Pages are deallocated/freed using
fallo
On 05/01/2017 11:30 PM, Prakash Sangappa wrote:
> Some applications like a database use hugetblfs for performance
> reasons. Files on hugetlbfs filesystem are created and huge pages
> allocated using fallocate() API. Pages are deallocated/freed using
> fallocate() hole punching support that has bee
Some applications like a database use hugetblfs for performance
reasons. Files on hugetlbfs filesystem are created and huge pages
allocated using fallocate() API. Pages are deallocated/freed using
fallocate() hole punching support that has been added to hugetlbfs.
These files are mmapped and acces
16 matches
Mail list logo
