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
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 [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.
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
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
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
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
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
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
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
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(>lru)
> if (!reclaim_mapped && other_conditions)
> list_add(>lru, _active);
> ...
>
> In the case mentioned
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
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
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
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
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
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
>
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
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
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
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
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
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
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].
>
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].
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
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
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
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
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
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
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
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
allocating
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
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
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
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:
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 can
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
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
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 case mentioned
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
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
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
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
50 matches
Mail list logo
