On Wed, 7 Nov 2007 09:59:45 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 6 Nov 2007 21:51:27 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote:
> > Which is why we need to greatly reduce the number of pages
> > scanned to free a page. In all workloads.
>
> It strikes me that splitting
> On Tue, 6 Nov 2007 21:51:27 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Nov 2007 18:40:46 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 6 Nov 2007, Rik van Riel wrote:
> >
> > > Also, a factor 16 increase in page size is not going to help
> > > if
On Wed, 7 Nov 2007 09:59:45 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007 21:51:27 -0500 Rik van Riel [EMAIL PROTECTED] wrote:
Which is why we need to greatly reduce the number of pages
scanned to free a page. In all workloads.
It strikes me that splitting one list
On Tue, 6 Nov 2007 21:51:27 -0500 Rik van Riel [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007 18:40:46 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, Rik van Riel wrote:
Also, a factor 16 increase in page size is not going to help
if memory sizes also
On Tue, 6 Nov 2007 18:40:46 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Nov 2007, Rik van Riel wrote:
>
> > Also, a factor 16 increase in page size is not going to help
> > if memory sizes also increase by a factor 16, since we already
> > have trouble with today's
On Tue, 6 Nov 2007, Rik van Riel wrote:
> Also, a factor 16 increase in page size is not going to help
> if memory sizes also increase by a factor 16, since we already
> have trouble with today's memory sizes.
Note that a factor 16 increase usually goes hand in hand with
more processors. The
On Tue, 6 Nov 2007 18:11:39 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 3 Nov 2007, Rik van Riel wrote:
>
> > The current version only has the infrastructure. Large changes to
> > the page replacement policy will follow later.
>
> H.. I'd rather see where we are
On Sat, 3 Nov 2007, Rik van Riel wrote:
> The current version only has the infrastructure. Large changes to
> the page replacement policy will follow later.
H.. I'd rather see where we are going. One other way of addressing
many of these issues is to allow large page sizes on the LRU which
On Sat, 3 Nov 2007, Rik van Riel wrote:
The current version only has the infrastructure. Large changes to
the page replacement policy will follow later.
H.. I'd rather see where we are going. One other way of addressing
many of these issues is to allow large page sizes on the LRU which
On Tue, 6 Nov 2007 18:11:39 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Sat, 3 Nov 2007, Rik van Riel wrote:
The current version only has the infrastructure. Large changes to
the page replacement policy will follow later.
H.. I'd rather see where we are going.
On Tue, 6 Nov 2007, Rik van Riel wrote:
Also, a factor 16 increase in page size is not going to help
if memory sizes also increase by a factor 16, since we already
have trouble with today's memory sizes.
Note that a factor 16 increase usually goes hand in hand with
more processors. The
On Tue, 6 Nov 2007 18:40:46 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007, Rik van Riel wrote:
Also, a factor 16 increase in page size is not going to help
if memory sizes also increase by a factor 16, since we already
have trouble with today's memory sizes.
The current page replacement scheme in Linux has a number of problems,
which can be boiled down to:
- Sometimes the kernel evicts the wrong pages, which can result in
bad performance.
- The kernel scans over pages that should not be evicted. On systems
with a few GB of RAM, this can result in
The current page replacement scheme in Linux has a number of problems,
which can be boiled down to:
- Sometimes the kernel evicts the wrong pages, which can result in
bad performance.
- The kernel scans over pages that should not be evicted. On systems
with a few GB of RAM, this can result in
14 matches
Mail list logo
