Rik van Riel <[EMAIL PROTECTED]> wrote:
CLOCK-Pro is still vulnerable to the cyclic scan use case, since at that
time all pages will have equal distance.
That's fixable. Just bias in favor of the already active
pages and only let pages with a clearly smaller interreference
distance replace the
Peter Zijlstra <[EMAIL PROTECTED]> said:
I'm still torn between CLOCK-Pro and CART.
CLOCK-Pro is still vulnerable to the cyclic scan use case, since at that
time all pages will have equal distance.
I was recently testing CLOCK-Pro for the entry cache in OpenLDAP, with this
cyclic scan case.
Peter Zijlstra wrote:
On Mon, 2007-01-22 at 18:03 -0800, Christoph Lameter wrote:
What happened to all those advanced page replacement endeavors?
They are here:
http://programming.kicks-ass.net/kernel-patches/page-replace/2.6.19-pr1/
I should update to .20 soonish.
What is the most promisin
On Mon, 2007-01-22 at 18:03 -0800, Christoph Lameter wrote:
> What happened to all those advanced page replacement endeavors?
They are here:
http://programming.kicks-ass.net/kernel-patches/page-replace/2.6.19-pr1/
I should update to .20 soonish.
> What is the most promising of those?
I'm still
Rik van Riel wrote:
Nick Piggin wrote:
The other nice thing about it was that it didn't have a hard
cutoff that the current reclaim_mapped toggle does -- you could
opt to scan the mapped list at a lower ratio than the unmapped
one. Of course, it also has some downsides too, and would
require re
Nick Piggin wrote:
Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
1. Currently based on swappiness, we might walk an entire list
searching for page cache pages or mapped pages. With these
lists s
Nick Piggin wrote:
The other nice thing about it was that it didn't have a hard
cutoff that the current reclaim_mapped toggle does -- you could
opt to scan the mapped list at a lower ratio than the unmapped
one. Of course, it also has some downsides too, and would
require retuning...
Here's a
Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
1. Currently based on swappiness, we might walk an entire list
searching for page cache pages or mapped pages. With these
lists separated, it should
On Tue, 23 Jan 2007, Balbir Singh wrote:
> Yes, good point, I see what you mean in terms of impact. But the trade
> off could come from shrink_active_list() which does
>
> list_del(&page->lru)
> if (!reclaim_mapped && other_conditions)
> list_add(&page->lru, &l_active);
> ...
>
> In the ca
Christoph Lameter wrote:
perfmon can do much of what you are looking for.
Thanks, I'll look into it.
--
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
Christoph Lameter wrote:
On Tue, 23 Jan 2007, Balbir Singh wrote:
When you unmap or map, you need to touch the pte entries and know the
pages involved, so shouldn't be equivalent to a list_del and list_add
for each page impacted by the map/unmap operation?
When you unmap and map you must curr
On Tue, 23 Jan 2007, Balbir Singh wrote:
> I have always wondered if it would be useful to have a kernel debug
> feature that can extract page references per task, it would be good
> to see the page references (last 'n') of a workload that is not
> doing too well on a particular system.
perfmon c
Rik van Riel wrote:
Christoph Lameter wrote:
With the proposed schemd you would have to move pages between lists if
they are mapped and unmapped by a process. Terminating a process could
lead to lots of pages moving to the unnmapped list.
That could be a problem.
Another problem is that any
On Tue, 23 Jan 2007, Balbir Singh wrote:
> When you unmap or map, you need to touch the pte entries and know the
> pages involved, so shouldn't be equivalent to a list_del and list_add
> for each page impacted by the map/unmap operation?
When you unmap and map you must currently get exclusive acc
Christoph Lameter wrote:
On Tue, 23 Jan 2007, Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
1. Currently based on swappiness, we might walk an entire list
searching for page cache pages or mapped p
Christoph Lameter wrote:
On Mon, 22 Jan 2007, Rik van Riel wrote:
The big one is how we are to do some background aging in a
clock-pro system, so referenced bits don't just pile up when
the VM has enough memory - otherwise we might not know the
right pages to evict when a new process starts up
On Mon, 22 Jan 2007, Rik van Riel wrote:
> The big one is how we are to do some background aging in a
> clock-pro system, so referenced bits don't just pile up when
> the VM has enough memory - otherwise we might not know the
> right pages to evict when a new process starts up and starts
> allocat
Christoph Lameter wrote:
On Mon, 22 Jan 2007, Rik van Riel wrote:
It would be really nice if we came up with a page replacement
algorithm that did not need many extra heuristics to make it
work...
I guess the "clock" type algorithms are the most promising in that
area. What happened to all t
On Tue, Jan 23, 2007 at 07:01:33AM +0530, Balbir Singh wrote:
> This makes me wonder if it makes sense to split up the LRU into page
> cache LRU and mapped pages LRU. I see two benefits
> 1. Currently based on swappiness, we might walk an entire list
>searching for page cache pages or mapped pa
On Mon, 22 Jan 2007, Rik van Riel wrote:
> It would be really nice if we came up with a page replacement
> algorithm that did not need many extra heuristics to make it
> work...
I guess the "clock" type algorithms are the most promising in that
area. What happened to all those advanced page repl
Christoph Lameter wrote:
With the proposed schemd you would have to move pages between lists if
they are mapped and unmapped by a process. Terminating a process could
lead to lots of pages moving to the unnmapped list.
That could be a problem.
Another problem is that any such heuristic in th
Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
Unlikely. I have seen several workloads fall over because they
did not throw out mapped pages soon enough.
If the kernel does not keep the most frequent
On Tue, 23 Jan 2007, Balbir Singh wrote:
> This makes me wonder if it makes sense to split up the LRU into page
> cache LRU and mapped pages LRU. I see two benefits
>
> 1. Currently based on swappiness, we might walk an entire list
>searching for page cache pages or mapped pages. With these
>
Andrea Arcangeli wrote:
On Tue, Jan 23, 2007 at 01:10:46AM +0100, Niki Hammler wrote:
Dear Linux Developers/Enthusiasts,
For a course at my university I'm implementing parts of an operating
system where I get most ideas from the Linux Kernel (which I like very
much). One book I gain information
On Tue, Jan 23, 2007 at 01:10:46AM +0100, Niki Hammler wrote:
> Dear Linux Developers/Enthusiasts,
>
> For a course at my university I'm implementing parts of an operating
> system where I get most ideas from the Linux Kernel (which I like very
> much). One book I gain information from is [1].
>
Dear Linux Developers/Enthusiasts,
For a course at my university I'm implementing parts of an operating
system where I get most ideas from the Linux Kernel (which I like very
much). One book I gain information from is [1].
Linux uses for its Page Replacing Algorithm (based on LRU) *two* chained
l
26 matches
Mail list logo
