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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
