Messages in this thread | | | Subject | Re: Autoregulate swappiness & inactivation | From | FabF <> | Date | Fri, 09 Jul 2004 11:48:07 +0200 |
| |
On Fri, 2004-07-09 at 03:05, Con Kolivas wrote: > FabF wrote: > > Con, > > What's interesting is try_to_free_pages comment : > > > > " the zone may be full of dirty or under-writeback pages, which this > > * caller can't do much about. We kick pdflush and take explicit naps > > in the > > * hope that some of these pages can be written. But if the allocating > > task..." > > > > I mean do we have high activity profile of that side of the kernel when > > bringing up some big application to life ? > > Does work consist here in 50% out, 50% in (time) ? Your anticipation > > algorithm can help the "in" side but maybe we can optimize yet the "out" > > side.btw, I'm surprised to see autoswappiness so far in fx tree: > > > > page_reclaim > > try_to_free_pages > > shrink_caches > > shrink_zone > > refill_inactive_zone > > auto_swap calculation > > > > > > IOW, does such parameter could not involve more decisions ? > > If you put it that way, yes - it would classify as duct tape. However > the code already acted based upon mapped_ratio which is pretty much all > this patch does. Folded in in that sample patch I sent out earlier you > can see that all it does is acted on mapped_ratio in a different manner > so it's not really an extra layer at all. > > - swap_tendency = mapped_ratio / 2 + distress + vm_swappiness; > + vm_swappiness = mapped_ratio * 150 / 100; > + vm_swappiness = vm_swappiness * vm_swappiness / 150; > + swap_tendency = distress + vm_swappiness;
Here's an easy benchmark to demonstrate problem : 1.Run Mozilla 2.Minimize 3=>Mozilla Resident Size (mrs) : 24Mb 4.Run updatedb 5.=>mrs : 15Mb 6.updatedb ends up 7.mrs doesn't move at all (yes, it goes down as I'm typing this msg :)).
So my question is : Don't we have a way to say "whose pages were reclaimed from and reattribute its" ? (having in mind memory status per se). IOW flushing (I guess it's pdflush relevant ? ) do work for dead processes but doesn't care about applications alive...
Regards, FabF
> > Con > > > Regards, > > FabF
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |