[PATCH] Jail Memory Limits

[Chris Jones]

On 6-Aug-06, at 9:08 AM, Alex Lyashkov wrote:

> I read you patch and see you start N kernel threads for control
> memory/CPU usage, when each thread in loop count total memory usage.
> What are reason why not create memory limit similar limit(1)?
> for this need add pointer to prison structure at each VMA struct  
> and add
> few checks at same points when LIMIT_VMEM and LIMIT_RSS checks.

Hi, Alex --- there are a few reasons I chose not to do it that way:

First, I think it makes more sense to limit memory over the jail as a  
whole, rather than against whichever process happens to hit the limit  
first; that suggests that the approach taken by limit(1) is probably  
not appropriate for my purposes.  I could use that as a trigger to  
launch the "push things out of physical memory" bit, but it seems a  
bit unnatural to me.  (I'm open to persuasion, though.)

Second, I think that it's valuable to be able to overcommit memory to  
some extent; that is, turning this into a soft-ish limit rather than  
a hard limit.  Being able to tune the response time, if you will, of  
enforcing the limit against a jail means that you could permit one  
jail to have a more lenient overcommit policy than another.

Third, there's precedent for this in other OSes: Solaris implements  
its resource limits for zones (analogous to jails) in a similar manner.

My apologies for not replying to this sooner; I've just got home from  
a few days' vacation in California, and to have worked on the project  
(I'm told including correspondence) while there would have not only  
been illegal for me but (worse!) created some major tax headaches.

I look forward to your thoughts.

Cheers,

Chris