linux-um.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Blaisorblade <blaisorblade@yahoo.it>
To: Rob Landley <rob@landley.net>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	Jeff Dike <jdike@addtoit.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Yasunori Goto <y-goto@jp.fujitsu.com>,
	Dave Hansen <haveblue@us.ibm.com>, linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	lhms <lhms-devel@lists.sourceforge.net>
Subject: Re: [uml-devel] Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
Date: Fri, 4 Nov 2005 18:18:03 +0100	[thread overview]
Message-ID: <200511041818.04397.blaisorblade@yahoo.it> (raw)
In-Reply-To: <200511040950.59942.rob@landley.net>

(Note - I've removed a few CC's since we're too many ones, sorry for any 
inconvenience).

On Friday 04 November 2005 16:50, Rob Landley wrote:
> On Thursday 03 November 2005 21:26, Blaisorblade wrote:
> > > 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. :)
Yep, right for your case... however currently the majority of users use tmpfs 
(I hope for them)...

> > I guess you refer to using frag. avoidance on the guest
>
> Yes.  Moot point since Linus doesn't want it.
See lwn.net last issue (when it becomes available) on this issue. In short, 
however, the real point is that we need this kind of support.

> Might be a performance issue if that gets introduced with per-page
> granularity,
I'm aware of this possibility, and I've said in fact "Frag. avoidance will be 
nice to use". However I'm not sure that the system call overhead is so big, 
compared to flushing the TLB entries...

But for now we haven't the issue - you don't do hotunplug frequently. When 
somebody will write the auto-hotunplug management daemon we could have a 
problem on this...
> and how do you avoid giving back pages we're about to re-use? 

Jeff's trick is call the buddy allocator (__get_free_pages()) to get a full 
page (and it will do any needed work to free memory), so nobody else will use 
it, and then madvise() it.

If a better API exists, that will be used.

> 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.
I couldn't parse your sentence. The allocation will free memory like when 
memory is needed.

However look at /proc/sys/vm/swappiness or use Con Kolivas's patches to find 
new tunable and policies.
> If there's already such a tuneable, I haven't found it yet.)
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2005-11-04 17:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1130917338.14475.133.camel@localhost>
     [not found] ` <20051102172729.9E7C.Y-GOTO@jp.fujitsu.com>
     [not found]   ` <43687C3D.7060706@yahoo.com.au>
2005-11-02 23:28     ` [uml-devel] Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 Rob Landley
2005-11-03  5:26       ` Jeff Dike
2005-11-03  5:41         ` Rob Landley
2005-11-04  3:26           ` Blaisorblade
2005-11-04 15:50             ` Rob Landley
2005-11-04 17:18               ` Blaisorblade [this message]
2005-11-04 17:44                 ` Rob Landley
2005-11-04 19:10                   ` Blaisorblade
2005-11-04 20:41                     ` Rob Landley
2005-11-04 20:57                       ` Rob Landley
2005-11-04 23:42                       ` Blaisorblade
2005-11-05  1:45                         ` Rob Landley
2005-11-05  5:23                           ` Jeff Dike
2005-11-05  5:45                       ` Jeff Dike
2005-11-05 11:30                         ` Blaisorblade
2005-11-05 23:44                           ` Rob Landley
2005-11-06 17:18                             ` Blaisorblade
2005-11-08  0:32                               ` Rob Landley
2005-11-08 15:56                                 ` Blaisorblade
2005-11-09  0:50                                   ` Rob Landley
2005-11-05 18:57                         ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200511041818.04397.blaisorblade@yahoo.it \
    --to=blaisorblade@yahoo.it \
    --cc=haveblue@us.ibm.com \
    --cc=jdike@addtoit.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rob@landley.net \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=y-goto@jp.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).