Re: differences between MADV_FREE and MADV_DONTNEED

On Tue, Jan 17, 2006 at 02:06:09AM +0100, Blaisorblade wrote:
> I.e. it's a restriction of MADV_REMOVE. Is there anything conceivable
> relying on errors or no behaviour on file-backed memory? If relying on
> errors we could need an API, but if relying only on the NO-OP thing the
> correctness semantics are already implemented. I.e. data are retained on both
> Solaris MADV_FREE and Linux MADV_REMOVE for file-backed case, they get a
> different semantics for caching.

Not sure to understand but merging MADV_REMOVE into MADV_FREE apparently
would break freebsd apps that might expect a noop instead. And it could
break Solaris apps if they execpt a -EINVAL (though the latter is more
dubious, but I doubt making differences is worth it and if freebsd makes
it a noop I'd stick with the noop and leave MADV_REMOVE alone).

> are the Solaris ones. Don't know past behaviour about "breaking existing to
> comply to standards" (new syscall slot?).

The change I suggested would be backwards compatible because it can only
affect performance.

The only thing that can break right now, is running a non-linux (and
apparently posix too) app on a linux system that will corrupt memory
with potential data loss.

> Provide our fine-grained semantics with new, not misunderstandable identifiers
> (MADV_FREE_DISCARD, MADV_FREE_CACHE, for instance).

Why should we deviate for the sake of porting pain, when we can comply
at no tangible risk for us?

> Making their apps work by causing the same breakage to Linux apps is a better
> idea?

Again: if an app breaks it means it's working by pure luck because it's
depending on fragile timings in the first place.

Call it a potential lower performance or less efficient memory
utilization, a breakage not.

If we were to make MADV_DONTNEED more aggressive, then we'd be risking a
breakage, but we're going to relax it instead.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Large Pages - Linux Foundation HPC
    ... -- Memory and interface to it - mapping memory into apps ... Some of their apps get a 6-7x speedup from large pages! ... Based on Dave's descriptions that HPC apps typically ... true of the kernel in general... ...
    (Linux-Kernel)
  • Re: Tech directions for Delphi?
    ... allocator, ... Most desktop apps build a relatively modest working set (a ... the case for .NET doesn't really rest on automatic memory ... management being cheaper overall than manual memory management. ...
    (borland.public.delphi.non-technical)
  • Re: Id appreciate your opinion(s)
    ... The fact that so much memory is used really doesn't mean you ... When it comes to all of the apps except for ones defined in the ... then I would say that .NET or Java are perfectly fine ... Java and .NET can both do "smart" clients, fat clients, or web-based ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: memory requirements of closed vs quit apps
    ... majority of programs remain open when all their windows are closed. ... they use bugger all memory - and are ... individual apps Real and Virtual memory entries. ... In order to push it out to swap, ...
    (uk.comp.sys.mac)
  • Re: memory requirements of closed vs quit apps
    ... Close those tabs. ... I'd imagine it's the OS just trying to work out which memory needs ... The UI thing is exacerbated by the behaviour of apps to ... IMO 1Gb of RAM should easily ...
    (uk.comp.sys.mac)
Loading