On Tue, Oct 08, 2013 at 04:12:02PM +0900, Minchan Kim wrote:
> On Tue, Oct 08, 2013 at 12:35:33AM -0400, KOSAKI Motohiro wrote:
> > (10/7/13 11:07 PM), Minchan Kim wrote:
> > >Hi KOSAKI,
> > >
> > >On Mon, Oct 07, 2013 at 10:51:18PM -0400, KOSAKI Motohiro wrote:
> > >>>Maybe, int madvise5(addr, len
On Tue, Oct 08, 2013 at 12:35:33AM -0400, KOSAKI Motohiro wrote:
> (10/7/13 11:07 PM), Minchan Kim wrote:
> >Hi KOSAKI,
> >
> >On Mon, Oct 07, 2013 at 10:51:18PM -0400, KOSAKI Motohiro wrote:
> >>>Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
> >>> &purged, &ret);
>
(10/7/13 11:07 PM), Minchan Kim wrote:
Hi KOSAKI,
On Mon, Oct 07, 2013 at 10:51:18PM -0400, KOSAKI Motohiro wrote:
Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
&purged, &ret);
Another reason to make it hard is that madvise(2) is tight coupled with
with vmas s
Hi KOSAKI,
On Mon, Oct 07, 2013 at 10:51:18PM -0400, KOSAKI Motohiro wrote:
> >Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
> > &purged, &ret);
> >
> >Another reason to make it hard is that madvise(2) is tight coupled with
> >with vmas split/merge. It needs mmap_s
Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
&purged, &ret);
Another reason to make it hard is that madvise(2) is tight coupled with
with vmas split/merge. It needs mmap_sem's write-side lock and it hurt
anon-vrange test performance much heavily and userland mig
On Mon, Oct 07, 2013 at 06:24:49PM -0700, H. Peter Anvin wrote:
> On 10/07/2013 05:13 PM, Minchan Kim wrote:
> >>
> >> The point is that MADV_DONTNEED is very similar in that sense,
> >> especially if allowed to be lazy. It makes a lot of sense to permit
> >> both scrubbing modes orthogonally.
> >
On 10/07/2013 05:13 PM, Minchan Kim wrote:
>>
>> The point is that MADV_DONTNEED is very similar in that sense,
>> especially if allowed to be lazy. It makes a lot of sense to permit
>> both scrubbing modes orthogonally.
>>
>> The point you're making has to do with withdrawal of permission to flus
On Tue, Oct 08, 2013 at 09:34:30AM +0900, Minchan Kim wrote:
> On Mon, Oct 07, 2013 at 05:18:40PM -0700, John Stultz wrote:
> > On 10/07/2013 05:13 PM, Minchan Kim wrote:
> > > Hello Peter,
> > >
> > > On Mon, Oct 07, 2013 at 04:59:40PM -0700, H. Peter Anvin wrote:
> > >> On 10/07/2013 04:54 PM, Jo
On Mon, Oct 07, 2013 at 05:18:40PM -0700, John Stultz wrote:
> On 10/07/2013 05:13 PM, Minchan Kim wrote:
> > Hello Peter,
> >
> > On Mon, Oct 07, 2013 at 04:59:40PM -0700, H. Peter Anvin wrote:
> >> On 10/07/2013 04:54 PM, John Stultz wrote:
> And wouldn't this apply to MADV_DONTNEED just as
On 10/07/2013 05:13 PM, Minchan Kim wrote:
> Hello Peter,
>
> On Mon, Oct 07, 2013 at 04:59:40PM -0700, H. Peter Anvin wrote:
>> On 10/07/2013 04:54 PM, John Stultz wrote:
And wouldn't this apply to MADV_DONTNEED just as well? Perhaps what we
should do is an enhanced madvise() call?
>>>
Hello Peter,
On Mon, Oct 07, 2013 at 04:59:40PM -0700, H. Peter Anvin wrote:
> On 10/07/2013 04:54 PM, John Stultz wrote:
> >>>
> >> And wouldn't this apply to MADV_DONTNEED just as well? Perhaps what we
> >> should do is an enhanced madvise() call?
> > Well, I think MADV_DONTNEED doesn't *have*
On 10/07/2013 05:03 PM, Minchan Kim wrote:
> Hello, John and Peter
>
> On Mon, Oct 07, 2013 at 04:14:21PM -0700, John Stultz wrote:
>> On 10/07/2013 03:56 PM, H. Peter Anvin wrote:
>>> I see from the change history of the patch that this was an madvise() at
>>> some point, but was changed into a se
Hello, John and Peter
On Mon, Oct 07, 2013 at 04:14:21PM -0700, John Stultz wrote:
> On 10/07/2013 03:56 PM, H. Peter Anvin wrote:
> > On 10/02/2013 05:51 PM, John Stultz wrote:
> >> From: Minchan Kim
> >>
> >> This patch adds new system call sys_vrange.
> >>
> >> NAME
> >>vrange - Mark or un
On 10/07/2013 04:54 PM, John Stultz wrote:
>>>
>> And wouldn't this apply to MADV_DONTNEED just as well? Perhaps what we
>> should do is an enhanced madvise() call?
> Well, I think MADV_DONTNEED doesn't *have* do to anything at all. Its
> advisory after all. So it may immediately wipe out any data
On 10/07/2013 04:46 PM, H. Peter Anvin wrote:
> On 10/07/2013 04:41 PM, John Stultz wrote:
>> You mark a chunk of memory as volatile, then at some point later, mark
>> its as non-volatile. The purge state tells you if the memory is still
>> there, or if we threw it out due to memory pressure. This
On 10/07/2013 04:41 PM, John Stultz wrote:
>
> You mark a chunk of memory as volatile, then at some point later, mark
> its as non-volatile. The purge state tells you if the memory is still
> there, or if we threw it out due to memory pressure. This lets the
> application regnerate the purged data
On 10/07/2013 04:26 PM, H. Peter Anvin wrote:
> On 10/07/2013 04:14 PM, John Stultz wrote:
>>> I see from the change history of the patch that this was an madvise() at
>>> some point, but was changed into a separate system call at some point,
>>> does anyone remember why that was? A quick look thr
On 10/07/2013 04:14 PM, John Stultz wrote:
>>
>> I see from the change history of the patch that this was an madvise() at
>> some point, but was changed into a separate system call at some point,
>> does anyone remember why that was? A quick look through my LKML
>> archives doesn't really make it
On 10/07/2013 03:56 PM, H. Peter Anvin wrote:
> On 10/02/2013 05:51 PM, John Stultz wrote:
>> From: Minchan Kim
>>
>> This patch adds new system call sys_vrange.
>>
>> NAME
>> vrange - Mark or unmark range of memory as volatile
>>
> vrange() is about as nondescriptive as one can get -- there
On 10/02/2013 05:51 PM, John Stultz wrote:
> From: Minchan Kim
>
> This patch adds new system call sys_vrange.
>
> NAME
> vrange - Mark or unmark range of memory as volatile
>
vrange() is about as nondescriptive as one can get -- there is exactly
one letter that has any connection with t
From: Minchan Kim
This patch adds new system call sys_vrange.
NAME
vrange - Mark or unmark range of memory as volatile
SYNOPSIS
int vrange(unsigned_long start, size_t length, int mode,
int *purged);
DESCRIPTION
Applications can use vrange(2) to
21 matches
Mail list logo
