Hi,
On Sunday, 5 November 2006 12:25, Pavel Machek wrote:
> Hi!
>
> > > > > Ok, maybe this is something we should look into later, since i really
> > > > > often
> > > > > see machine freeing memory for 30 seconds, snapshotting for another
> > > > > 20 seconds
> > > > > and then writing for 10 seconds (or at least it feels like that :-).
> > > >
> > > > The freeing of memory for 30 sec. happens if there are lots of slabs
> > > > before
> > > > the suspend. The memory shrinker is not good at freeing slab caches,
> > > > to say
> > > > the least, but this stuff is quite complicated.
> > >
> > > I'll probably put some timing around those steps in uswsusp debug mode, so
> > > we can see it.
> >
> > Unfortunately the shrinking of memory is done as a part of the atomic
> > snapshot, but I have a patch to measure the time it takes which I'm going to
> > send to LKML in a while.
>
> Could memory freeing be separated into separate ioctl()? That would
> allow us to do interruptible freeing (in small hunks), and allow
> timing done from userland...
Well, I prefer the timing being done by the kernel, because it's easliy
grepable in the dmesg output and it can be done for the built-in swsusp in the
same way.
As far as the interruptible freeing is concerned, is it _really_ that
important? Currently the shrinking of memory is common code and I don't think
the interruptibility is a good enough reason to make things more complicated
than they have to be. At least not _now_.
> > > And it _is_ machine / setup dependent. The machine i am using right now is
> > > fast (Toughbook CF51), the one i was using before (nx5000) was dead slow.
> > > This was also the machine, where compression did nothing good, although it
> > > should have been almost equal to the toughbook wrt CPU and RAM.
> > > It might also depend on filesystems used or disk layout or whatever,
> > > because
> > > Pavel once also had an nx5000 and never saw the slowness that i did (but
> > > that
> > > was years ago).
> > > So having some timing in a debug mode might actually help test this out,
> > > because numbers are a better measure than "it feels slow" :-)
> >
> > uswsusp (Can we call it differently please? Suggestions welcome. ;-))
> > actually measures the time of writing to the disk as well as the time of
> > reading from it which are printed during the resume, The only missing thing
> > is the option to wait for a key after they have been printed so that the
> > user can read them.
>
> Could we just print them at the end of the whole sequence, so that
> user sees them at the end?
That would be tricky, because they are lost when the memory contents from
before the suspend are restored. To print them at the very end we'd have to
write them into the swap header, for example.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
