On Tuesday 18 April 2006 12:13, Andrew Morton wrote:
> "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > Rework the swsusp's memory shrinker in the following way:
>
> And what was the observed effect of all this?
Measurable effects:
1) It tends to free only as much memory as required, eg. if the image_size
is set to 450 MB, the actual image sizes are almost always well above
400 MB and they tended to be below that number without the patch
(~5-10% of a difference, but still :-)).
2) If image_size = 0, it frees everything that can be freed without any
workarounds (we had to add the additional loop checking for
ret >= nr_pages with the additional blk_congestion_wait() to the
"original" shrinker to achieve this).
A non-measurable effect is that with the patch applied the system seems to
be more responsive after resume, but of course this may be an illusion.
>
> > + /* Force reclaiming mapped pages in the passes #3 and #4 */
> > + if (pass > 2) {
> > + sc.may_swap = 1;
> > + vm_swappiness = 100;
> > + }
>
> That's a bit klunky. Maybe we should move swappiness into scan_control.
Alternatively we can temporarily set zone->prev_priority to 100 in
shrink_all_zones() if pass > 2?
-
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]
