>>So what to do when virtual physical limit is hit? >>OOM-kill current task? > > > when the RSS limit is hit, but there _are_ enough > pages left on the physical system, there is no > good reason to swap out the page at all > > - there is no benefit in doing so (performance > wise, that is) > > - it actually hurts performance, and could > become a separate source for DoS > > what should happen instead (in an ideal world :) > is that the page is considered swapped out for > the guest (add guest penality for swapout), and > when the page would be swapped in again, the guest > takes a penalty (for the 'virtual' page in) and > the page is returned to the guest, possibly kicking > out (again virtually) a different page
great. I agree with that. Just curious why current vserver code kills arbitrary task in container then? >>> - accounting and limits have to be consistent >>> and should roughly represent the actual used >>> memory/swap (modulo optimizations, I can go >>> into detail here, if necessary) >> >>This is true for current implementation for >>booth - this patchset ang OpenVZ beancounters. >> >>If you sum up the physpages values for all containers >>you'll get the exact number of RAM pages used. > > > hmm, including or excluding the host pages? depends on whether you will include beanocunter 0 usages or not :) Kirill - 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/