On Tuesday 08 November 2005 09:56, Blaisorblade wrote:
> But hey, it's (now) standard practice to loopback-mount root_fs images to
> alter them. I've been using linux since less than 3 years (say RedHat 7.3
> was my first distro), though, so I can't remember about before.
Red Hat 5.something here.
On Tuesday 08 November 2005 01:32, Rob Landley wrote:
> On Sunday 06 November 2005 11:18, Blaisorblade wrote:
> In theory the host should get this right, though. What I really want is
> ionice, and I'm under the impression that one of the schedulers made this
> possible a few months back. Dunno
On Sunday 06 November 2005 11:18, Blaisorblade wrote:
> > In theory, the state of truly free memory is irrelevant. The fact
> > madvise zeroes it out is nice, but not actually required. (And I'm not
> > sure madvise would actually zero if /tmp isn't tmpfs, so relying on the
> > zeroing behavior m
On Sunday 06 November 2005 00:44, Rob Landley wrote:
> On Saturday 05 November 2005 05:30, Blaisorblade wrote:
> > I've proposed in fact including (for now) another of Con's patch, which
> > gives some preference to free memory over pagecache (to speed up page
> > allocation)... but I don't quite u
On Saturday 05 November 2005 05:30, Blaisorblade wrote:
> I've proposed in fact including (for now) another of Con's patch, which
> gives some preference to free memory over pagecache (to speed up page
> allocation)... but I don't quite understand why no Con's patches get
> merged, at least in -mm
On Friday 04 November 2005 23:45, Jeff Dike wrote:
> > If we get prezeroing, the tunable is useful. If we haven't got
> > prezeroing, this infrastructure probably won't get in.
>
> I'm not really convinced that prezeroing would be that useful, particularly
> through madvise. The reason is that th
On Saturday 05 November 2005 06:45, Jeff Dike wrote:
> On Fri, Nov 04, 2005 at 02:41:11PM -0600, Rob Landley wrote:
> > On Friday 04 November 2005 13:10, Blaisorblade wrote:
> > > > What I was thinking is that if we get prezeroing infrastructure that
> > > > can use various prezeroing accelerators
On Fri, Nov 04, 2005 at 02:41:11PM -0600, Rob Landley wrote:
> On Friday 04 November 2005 13:10, Blaisorblade wrote:
> > > What I was thinking is that if we get prezeroing infrastructure that can
> > > use various prezeroing accelerators (as has been discussed but I don't
> > > believe merged), the
On Fri, Nov 04, 2005 at 07:45:53PM -0600, Rob Landley wrote:
> Another advantage of prezeroing: it maps really well to what we're trying to
> do here. It makes a class of not just free but zeroed memory (and madvise
> zeroes the memory for us).
Yeah, we would need to keep track of zeroed page
On Friday 04 November 2005 17:42, Blaisorblade wrote:
> > That's more configuration on the host that's not really needed. Doesn't
> > do my case any good.
>
> We'll consider your case too then... for your job the daemon could be done
> by a thread started by UML on the host. The idea (still very p
Jeff, some input for you - can you have a look?
On Friday 04 November 2005 21:41, Rob Landley wrote:
> On Friday 04 November 2005 13:10, Blaisorblade wrote:
> > > If you've got a daemon running in the virtual system to hand back
> > > memory to the host, then you don't need a tuneable.
> >
> > I t
On Friday 04 November 2005 14:41, Rob Landley wrote:
> seconds. (Yeah, 20 gigs/second on linear reads. Not quite so much on an
Megs, obviously. Not _that_ cool of a laptop...
Rob
---
SF.Net email is sponsored by:
Tame your development challe
On Friday 04 November 2005 13:10, Blaisorblade wrote:
> > If you've got a daemon running in the virtual system to hand back memory
> > to the host, then you don't need a tuneable.
>
> I think Jeff's idea was a daemon running on the host (not as root) to
> manage splitting of memory between UMLs (an
(Ok, now the thing is UML-only).
On Friday 04 November 2005 18:44, Rob Landley wrote:
> On Friday 04 November 2005 11:18, Blaisorblade wrote:
> > > 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
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 ze
On Friday 04 November 2005 11:18, Blaisorblade wrote:
> > 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
> m
(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_
On Thursday 03 November 2005 06:41, Rob Landley wrote:
> On Wednesday 02 November 2005 23:26, Jeff Dike wrote:
> > On Wed, Nov 02, 2005 at 05:28:35PM -0600, Rob Landley wrote:
> > > With fragmentation reduction and prezeroing, UML suddenly gains the
> > > option of calling madvise(DONT_NEED) on suf
On Wednesday 02 November 2005 23:26, Jeff Dike wrote:
> On Wed, Nov 02, 2005 at 05:28:35PM -0600, Rob Landley wrote:
> > With fragmentation reduction and prezeroing, UML suddenly gains the
> > option of calling madvise(DONT_NEED) on sufficiently large blocks as A) a
> > fast way of prezeroing, B) a
On Wed, Nov 02, 2005 at 05:28:35PM -0600, Rob Landley wrote:
> With fragmentation reduction and prezeroing, UML suddenly gains the option of
> calling madvise(DONT_NEED) on sufficiently large blocks as A) a fast way of
> prezeroing, B) a way of giving memory back to the host OS when it's not in
On Wednesday 02 November 2005 02:43, Nick Piggin wrote:
> > Hmmm. I don't see at this point.
> > Why do you think ZONE_REMOVABLE can satisfy for hugepage.
> > At leaset, my ZONE_REMOVABLE patch doesn't any concern about
> > fragmentation.
>
> Well I think it can satisfy hugepage allocations simply
21 matches
Mail list logo
