On Wed, 22 Apr 2009 22:11:17 +0200 "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: > On Wednesday 22 April 2009, Pavel Machek wrote: > > Hi! > > > > > Of course, this will protect the calling task from getting oom-killed. > > > But it doesn't protect other tasks from getting oom-killed due to the > > > activity of _this_ task. > > > > > > But I think that problem already exists, and that this proposal doesn't > > > worsen anything, yes? > > > > > > Or is it the case that all other tasks are safely stuck in the freezer > > > at this time, so they won't be allocating any memory anyway? > > > > That is the idea, yes. ... but we now have more threads that are not > > freezable... so they may allocate the memory. > > > > Is it non-feasible to free memory without really going and allocating > > everything? > > The question is whether there is a point. In principle we can just go and > allocate as much as we need upfront. It shouldn't change anything, because > we resume and suspend devices after creating the image anyway. > > I think we could try to disable the OOM killer before suspend and just > allocate the memory for the image right before devices are suspended for the > first time. > It would be nice to do. shrink_all_memory() is simply trying to do something which page reclaim doesn't expect to do (free memory when there's already lots of memory free). Consequently it doesn't do it very well, and there's a good risk that changes to core reclaim will accidentally break shrink_all_memory(). -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
