Messages in this thread |  | | | Date | Tue, 17 Jan 2006 02:33:47 +0100 | | From | Andrea Arcangeli <> | | Subject | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |