On 07/04/2017 09:40 AM, Andrea Arcangeli wrote:
On Fri, Jun 30, 2017 at 05:55:08PM -0700, prakash sangappa wrote:
Interesting that UFFDIO_COPY is faster then fallocate(). In the DB use case
the page does not need to be allocated at the time a process trips on
the hugetlbfs
file hole and recei
On Fri, Jun 30, 2017 at 2:47 AM, Michal Hocko wrote:
> [CC John, the thread started
> http://lkml.kernel.org/r/9363561f-a9cd-7ab6-9c11-ab9a99dc8...@oracle.com]
>
> On Thu 29-06-17 14:41:22, prakash.sangappa wrote:
>>
>>
>> On 06/29/2017 01:09 AM, Michal Hocko wrote:
>> >On Wed 28-06-17 11:23:32, P
On Fri, Jun 30, 2017 at 05:55:08PM -0700, prakash sangappa wrote:
> Interesting that UFFDIO_COPY is faster then fallocate(). In the DB use case
> the page does not need to be allocated at the time a process trips on
> the hugetlbfs
> file hole and receives SIGBUS. fallocate() is called on the hu
On 6/30/2017 6:08 AM, Andrea Arcangeli wrote:
On Fri, Jun 30, 2017 at 11:47:35AM +0200, Michal Hocko wrote:
[...]
As an aside, I rememeber that prior to MADV_FREE there was long
discussion about lazy freeing of memory from userspace. Some users
wanted to be signalled when their memory was free
On Fri, Jun 30, 2017 at 11:47:35AM +0200, Michal Hocko wrote:
> [CC John, the thread started
> http://lkml.kernel.org/r/9363561f-a9cd-7ab6-9c11-ab9a99dc8...@oracle.com]
>
> On Thu 29-06-17 14:41:22, prakash.sangappa wrote:
> >
> >
> > On 06/29/2017 01:09 AM, Michal Hocko wrote:
> > >On Wed 28-06
[CC John, the thread started
http://lkml.kernel.org/r/9363561f-a9cd-7ab6-9c11-ab9a99dc8...@oracle.com]
On Thu 29-06-17 14:41:22, prakash.sangappa wrote:
>
>
> On 06/29/2017 01:09 AM, Michal Hocko wrote:
> >On Wed 28-06-17 11:23:32, Prakash Sangappa wrote:
> >>
> >>On 6/28/17 6:18 AM, Mike Rapopo
On 06/29/2017 03:46 AM, Mike Rapoport wrote:
On Wed, Jun 28, 2017 at 11:23:32AM -0700, Prakash Sangappa wrote:
[...]
Will this result in a signal delivery?
In the use case described, the database application does not need any event
for hole punching. Basically, just a signal for any invali
On 06/29/2017 01:09 AM, Michal Hocko wrote:
On Wed 28-06-17 11:23:32, Prakash Sangappa wrote:
On 6/28/17 6:18 AM, Mike Rapoport wrote:
[...]
I've just been thinking that maybe it would be possible to use
UFFD_EVENT_REMOVE for this case. We anyway need to implement the generation
of UFFD_EVE
On Wed, Jun 28, 2017 at 11:23:32AM -0700, Prakash Sangappa wrote:
>
>
> On 6/28/17 6:18 AM, Mike Rapoport wrote:
> >On Tue, Jun 27, 2017 at 09:01:20AM -0700, Prakash Sangappa wrote:
> >>On 6/27/17 8:35 AM, Mike Rapoport wrote:
> >>
> >>>On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote
On Wed 28-06-17 11:23:32, Prakash Sangappa wrote:
>
>
> On 6/28/17 6:18 AM, Mike Rapoport wrote:
[...]
> >I've just been thinking that maybe it would be possible to use
> >UFFD_EVENT_REMOVE for this case. We anyway need to implement the generation
> >of UFFD_EVENT_REMOVE for the case of hole punc
On 6/28/17 6:18 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:01:20AM -0700, Prakash Sangappa wrote:
On 6/27/17 8:35 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17
On Tue, Jun 27, 2017 at 09:01:20AM -0700, Prakash Sangappa wrote:
> On 6/27/17 8:35 AM, Mike Rapoport wrote:
>
> >On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
> >>This is an user visible API so let's CC linux-api mailing list.
> >>
> >>On Mon 26-06-17 12:46:13, Prakash Sangappa wr
On 6/27/17 8:35 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
to
On 6/27/17 12:06 AM, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
to the faulting process, instead of the page-fault event. Dealing
On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
> This is an user visible API so let's CC linux-api mailing list.
>
> On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
> > In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
> > to the faulting process, instead of
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
> In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
> to the faulting process, instead of the page-fault event. Dealing with
> page-fault event using a monitor t
In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
to the faulting process, instead of the page-fault event. Dealing with
page-fault event using a monitor thread can be an overhead in these
cases. For example applications like the database could use the signaling
mechanism fo
17 matches
Mail list logo
