Messages in this thread | | | Date | Thu, 12 Jun 2003 16:03:41 -0700 (PDT) | From | Muthian Sivathanu <> | Subject | RE: limit resident memory size |
| |
well, the goal is to enforce strict upper bounds on how much resources a process can consume, including memory, disk bandwidth etc. I understand that this may not give the best aggregate system performance, but so is any proportional sharing scheme. The impact of swapping/paging on the other processes can be minimized by rate-limiting the disk I/O that the process does, for swapping or anything else.
Muthian.
--- David Schwartz <davids@webmaster.com> wrote: > > > I would like to limit the maximum resident memory > size > > of a process within a threshold, i.e. if its > virtual > > memory footprint exceeds this threshold, it needs > to > > swap out pages *only* from within its VM space. > > Why? If you think this is a good way to be nice to > other processes, you're > wrong. > > > First, is there a way this can be done at > application > > level ? The setrlimit interface seems to contain > an > > option for specifying max resident set size, but > it > > doesnt seem like it is implemented as of 2.4 -- am > I > > wrong ? > > > If the kernel doesnt currently support it, is > there an > > efficient way (data structure etc) to traverse the > > resident set of a *process* in lru fashion ? All > the > > page replacement and swapping code work on the > entire > > page lists -- is there any simple way to group > these > > per process ? > > One process paging and swapping excessively will > hurt other processes that > aren't. What's your outer problem? What you're > trying to do doesn't seem to > have any rational purpose. > > DS > >
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - 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/
| |