Messages in this thread | | | From | "Roger Heflin" <> | Subject | RE: RSS Limit implementation issue | Date | Thu, 30 Mar 2006 15:41:57 -0600 |
| |
> > A process has no control over its RSS size, only its virtual > size. I'm not sure you're clear on that, or just not saying > it clearly. Therefore the same process, say a largish perl > run, may be 175mB in vsize, and during the day have rss of > perhaps half that. At night, with next to no load on the > machine, the rss is 175mB because there is a bunch of free > memory available. > > If you want to make rss a hard limit the result should be > swapping, not failure to run. I'm not sure the limit in that > form is a good idea, and before someone reminds me, I do > remember liking it better a few years ago.
working_set_size limits sucked on VMS. The OS would limit a process to its working set size and casue the entire machine to swap even though there was adequate free memory. I believe they had a normalworkingset size variable, and a maxworkingsetsize one indicated how much ram you could get on a memory limited system, the other indicated the most it would ever let you get even if there was plenty of free ram. The maxworkingsetsize caused a lot of issues, as the default appeared to be defined for much smaller systems that we were using at the time, and so were much too low, and cause unnecessary swapping. Part of the issue would be that the admin would need to know what he was doing to use the feature, and most don't.
The argument from the admins at the time was that this limited the damage to other processes by preventing certain processes from getting too much memory, they ignored the fact that anything swapping (even only the one process) unnecessarly *KILLED* performance for the entire machine, since swapping is rather expensive on the os.
Roger
- 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/
| |