lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RSS Limit implementation issue
Date
On Feb 10, 2006, at 09:50, Ram Gupta wrote:
> On 2/9/06, Alan Cox <alan@lxorguk.ukuu.org.uk> 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 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/

\
 
 \ /
  Last update: 2006-02-10 17:34    [W:0.109 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site