Hi,
On Monday 27 February 2006 00:52, Pavel Machek wrote:
> On Po 27-02-06 00:32:24, Rafael J. Wysocki wrote:
> > On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > > > them, and it freed more memory at later tries.
> > > > > >
> > > > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > > > than .5 sec.
> > > > >
> > > > > I was using this with some success... (Warning, against old
> > > > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > > > fix shrink_all_memory.
> > > >
> > > > Appended is a patch against the current -mm.
> > > > [It also makes
> > > > swsusp_shrink_memory() behave as documented for image_size = 0.
> > > > Currently, if it states there's enough free RAM to suspend, it won't bother
> > > > to free a single page.]
> > >
> > > Could we get bugfix part separately?
> >
> > Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
> > it's simple enough) ...
>
> Are you sure? The way I read old code ... it looks correct to me.
>
> size is always > 1000 or so. if image_size = 0, size >
> image_size/PAGE_SIZE and we'll loop as long as shrink_all_memory()
> frees something.
Of course, you are right.
So the original patch was what's needed to get the workaround in. :-)
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
