lkml.org 
[lkml]   [2005]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: wrong madvise(MADV_DONTNEED) semantic
Jörn Engel wrote:
> On Tue, 28 June 2005 16:05:11 -0400, Robert Love wrote:
>
>>I like the idea (I think someone suggested this early on) of renaming
>>the current MADV_DONTNEED to MADV_FREE and then adding a correct
>>MADV_DONTNEED.
>
>
> Imo, that's still a crime against common sense. Madvice should give
> the kernel some advice about which data to keep or not to keep in
> memory, hence the name. It should *not* tell the kernel to corrupt
> data, which currently appears to be the case.
>
> If the application knows 100% that it is the _only_ possible user of
> this data and will never again use it, dropping dirty pages might be a
> sane option. Effectively that translates to anonymous memory only.
> In all other cases, dirty pages should be written back.

There is also the case of shmget/shmat memory segments. Some
applications will use these in order to map a very large amount of
memory and then madvise(MADV_DONTNEED) in order to play nice with the
rest of the system should memory pressure / system load / etc require
it. Obviously if other tasks have these segments mapped, the pages
cannot be discarded. If a task is the sole "mapper" of the region and
doesn't need that memory (ever again) it would be good to avoid the i/o
overhead of swapping it out and just discarding it. Perhaps
MADV_DONTNEED isn't the right place for this, but there is demand for
this behavior.

--Darren Hart

>
>
>>And, as I said, the man page needs clarification.
>
>
> Definitely.
>
> Jörn
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-06 01:45    [W:1.030 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site