Re: [uml-devel] Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

On Thursday 03 November 2005 21:26, Blaisorblade wrote:

quoted

I was hoping that since the file was deleted from disk and is already
getting _some_ special treatment (since it's a longstanding "poor man's
shared memory" hack), that madvise wouldn't flush the data to disk, but
would just zero it out.  A bit optimistic on my part, I know. :)

I read at some time that this optimization existed but was deemed obsolete
and removed.

Why obsolete? Because... we have tmpfs! And that's the point. With
DONTNEED, we detach references from page tables, but the content is still
pinned: it _is_ the "disk"! (And you have TMPDIR on tmpfs, right?)

If I had that kind of control over environment my build would always be 
deployed in (including root access), I wouldn't need UML. :)

(P.S. The default for Ubuntu "Horny Hedgehog" is no.  The only tmpfs mount 
is /dev/shm, and /tmp is on / which is ext3.  Yeah, I need to upgrade my 
laptop...)

I guess you refer to using frag. avoidance on the guest

Yes.  Moot point since Linus doesn't want it.

(if it matters for 
the host, let me know). When it will be present using it will be nice, but
currently we'd do madvise() on a page-per-page basis, and we'd do it on
non-consecutive pages (basically, free pages we either find or free or
purpose).

Might be a performance issue if that gets introduced with per-page 
granularity, and how do you avoid giving back pages we're about to re-use?  
Oh well, bench it when it happens.  (And in any case, it needs a tunable to 
beat the page cache into submission or there's no free memory to give back.  
If there's already such a tuneable, I haven't found it yet.)

Rob

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>