On Thursday 05 July 2001 16:00, Xavier Bestel wrote:
> On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
> > Here's an idea I just came up with while I was composing this... along
> > the lines of using unused bandwidth for something that at least has a
> > chance of being useful. Suppose we come to the end of a period of
> > activity, the general 'temperature' starts to drop and disks fall idle.
> > At this point we could consult a history of which currently running
> > processes have been historically active and grow their working sets by
> > reading in from disk. Otherwise, the memory and the disk bandwidth is
> > just wasted, right? This we can do inside the kernel and not require
> > coders to mess up their apps with hints. Of course, they should still
> > take the time to reengineer them to reduce the cache footprint.
>
> Well, on a laptop memory and disk bandwith are rarely wasted - they cost
> battery life.
Let me comment on this again, having spent a couple of minutes more
thinking about it. Would you be happy paying 1% of your battery life to get
80% less sluggish response after a memory pig exits?
Also, notice that the scenario we were originally discussing, the off-hours
updatedb, doesn't normally happen on laptops because they tend to be
suspended at that time.
--
Daniel
On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote:
> > Well, on a laptop memory and disk bandwith are rarely wasted - they cost
> > battery life.
>
> Let me comment on this again, having spent a couple of minutes more
> thinking about it. Would you be happy paying 1% of your battery life to get
> 80% less sluggish response after a memory pig exits?
Told like this, of course I agree !
> Also, notice that the scenario we were originally discussing, the off-hours
> updatedb, doesn't normally happen on laptops because they tend to be
> suspended at that time.
Suspended != halted. The updatedb stuff starts over when I bring it back
to life (RH6.2, dunno for other distribs)
Xav
Daniel Phillips <[email protected]> writes:
> Also, notice that the scenario we were originally discussing, the off-hours
> updatedb, doesn't normally happen on laptops because they tend to be
> suspended at that time.
No, even worse, it happens when you open the laptop for the first time
in the morning, thanks to anacron.
--
Alan Shutko <[email protected]> - In a variety of flavors!
For children with short attention spans: boomerangs that don't come back.
On Thu, 5 Jul 2001, Daniel Phillips wrote:
> Let me comment on this again, having spent a couple of minutes
> more thinking about it. Would you be happy paying 1% of your
> battery life to get 80% less sluggish response after a memory
> pig exits?
Just to pull a few random numbers out of my ass too,
how about 50% of battery life for the same optimistic
80% less sluggishness ?
How about if it were only 30% of battery life?
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
On Friday 06 July 2001 21:09, Rik van Riel wrote:
> On Thu, 5 Jul 2001, Daniel Phillips wrote:
> > Let me comment on this again, having spent a couple of minutes
> > more thinking about it. Would you be happy paying 1% of your
> > battery life to get 80% less sluggish response after a memory
> > pig exits?
>
> Just to pull a few random numbers out of my ass too,
> how about 50% of battery life for the same optimistic
> 80% less sluggishness ?
>
> How about if it were only 30% of battery life?
It's not as random as that. The idea being considered was: suppose a
program starts up, goes through a period of intense, cache-sucking
activity, then exits. Could we reload the applications it just
displaced so that the disk activity to reload them doesn't have to take
place the first time the user touches the keyboard/mouse. Sure, we
obviously can, with how much complexity is another question entirely ;-)
So probably, we could eliminate more than 80% of the latency we now see
in such a situation, I was being conservative.
Now what's the cost in battery life? Suppose it's a 128 meg machine,
1/3 filled with program text and data. Hopefully, the working sets
that were evicted are largely coherent so we'll read it back in at a
rate not too badly degraded from the drive's transfer rate, say 5
MB/sec. This gives about three seconds of intense reading to restore
something resembling the previous working set, then the disk can spin
down and perhaps the machine will suspend itself. So the question is,
how much longer did the machine have to run to do this? Well, on my
machine updatedb takes 5-10 minutes, so the 3 seconds of activity
tacked onto the end of the episode amounts to less than 1%, and this is
where the 1% figure came from.
I'm not saying this would be an easy hack, just that it's possible and
the numbers work.
--
Daniel