On Feb 10, 2006, at 09:50, Ram Gupta wrote:
On 2/9/06, Alan Cox <[email protected]> wrote:
That is what I would expect. Or perhaps even allowing the process
to exceed the RSS but using the RSS limit as a swapper target so
that the process is victimised early. No point forcing swapping
and the RSS limit when there is free memory, only where the
resource is contended ..
So we will need some kind of free memory threshold . If free memory
is more than it than we can let RSS exceed & scheduler can also
schedule it in this situation but not if free memory is less than
the threshhold. Also we need to figure out a way for swapper to
target pages based on RSS limit. One possible disadvantage I can
think is that as the swapper swaps out a page based on RSS limit ,
the process's rss will become within the rss limit & then scheduler
will schedule this process again & hence possibly same page might
have to be brought in. This may cause increase in swapping. What do
you think how much realistic is this scenario?
Just use a basic hysteresis device:
When allocating resources:
if (resource > limit + delta)
disable_process();
When freeing resources:
if (resource < limit - delta)
enable_process();
If the delta is set to something reasonable (say 1 or 2 pages), then
the process will only be rescheduled when it gets enough free RSS
(one page to satisfy its latest request and a few spare). Even
better, you could use a running average of "time between RSS-
triggered-pauses" to figure out how much memory you should keep free.
Pseudocode below:
[Tuneables]
unsigned int time_quantum_factor;
unsigned int limit;
unsigned int max_delta;
[Per-process state]
unsigned int pages;
unsigned int delta;
unsigned long long last_limit_time;
[When allocating resources]
if (pages > limit + delta) {
int time_factor = log2(now - last_limit_time)
- time_quantum_factor;
last_limit_time = now;
if (time_factor < 0 && delta < max_delta)
delta <<= 1;
else if (time_factor > 0 && delta > 1)
delta >>= 1;
put_process_to_sleep();
}
[When freeing resources]
if (resource < limit - delta)
enable_process();
The effect of this code would be that the RSS code would avoid
rescheduling a process more often than every 1<<time_quantum_factor
microseconds. It would attempt to provide a safe hysteresis delta
such that the process would have enough pages free that it could
probably run for at least the minimum amount of time. Note that the
code would _only_ have an effect if the process is already about to
sleep on an RSS limit, otherwise that code path would never get hit.
Obviously it's possible to adjust this algorithm to react more slowly
or quickly by adjusting the shift values, but it should work well
enough for a beta as-is.
Cheers,
Kyle Moffett
--
I didn't say it would work as a defense, just that they can spin that
out for years in court if it came to it.
-- Rob Landley
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
