> On Thu, 15 Mar 2007 00:31:18 -0700 (PDT) David Miller <[EMAIL PROTECTED]>
> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 15 Mar 2007 00:22:49 -0800
>
> > So... what would happen if sparc64 were to use neither quicklists nor
> > slab? Just grab these pages from the page
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 15 Mar 2007 00:22:49 -0800
> So... what would happen if sparc64 were to use neither quicklists nor
> slab? Just grab these pages from the page allocator and clear them?
The page table allocator is heavier weight than the quicklists,
although
> On Mon, 12 Mar 2007 19:32:11 -0700 (PDT) David Miller <[EMAIL PROTECTED]>
> wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Mon, 12 Mar 2007 19:26:16 -0700 (PDT)
>
> > From: Paul Mackerras <[EMAIL PROTECTED]>
> > Date: Tue, 13 Mar 2007 11:37:32 +1100
> >
> > > David Miller writes:
> >
On Mon, 12 Mar 2007 19:32:11 -0700 (PDT) David Miller [EMAIL PROTECTED]
wrote:
From: David Miller [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 19:26:16 -0700 (PDT)
From: Paul Mackerras [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 11:37:32 +1100
David Miller writes:
I ported this
From: Andrew Morton [EMAIL PROTECTED]
Date: Thu, 15 Mar 2007 00:22:49 -0800
So... what would happen if sparc64 were to use neither quicklists nor
slab? Just grab these pages from the page allocator and clear them?
The page table allocator is heavier weight than the quicklists,
although
On Thu, 15 Mar 2007 00:31:18 -0700 (PDT) David Miller [EMAIL PROTECTED]
wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Thu, 15 Mar 2007 00:22:49 -0800
So... what would happen if sparc64 were to use neither quicklists nor
slab? Just grab these pages from the page allocator and
On Mon, Mar 12, 2007 at 03:51:57PM -0700, David Miller wrote:
> Someone with some extreme patience could do the sparc 32-bit port too,
> in fact it's lacking the cached PGD update logic that x86 et al. have
> so it would even end up being a bug fix :-) This lack is why sparc32
> pre-initializes
On Mon, Mar 12, 2007 at 03:51:57PM -0700, David Miller wrote:
Someone with some extreme patience could do the sparc 32-bit port too,
in fact it's lacking the cached PGD update logic that x86 et al. have
so it would even end up being a bug fix :-) This lack is why sparc32
pre-initializes the
From: David Miller <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 19:26:16 -0700 (PDT)
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Tue, 13 Mar 2007 11:37:32 +1100
>
> > David Miller writes:
> >
> > > I ported this to sparc64 as per the patch below, tested on
> > > UP SunBlade1500 and 24 cpu
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 11:37:32 +1100
> David Miller writes:
>
> > I ported this to sparc64 as per the patch below, tested on
> > UP SunBlade1500 and 24 cpu Niagara T1000.
>
> Did you see any performance improvement? We used to have quicklists
> on ppc,
On Tue, 13 Mar 2007, Paul Mackerras wrote:
> Also, I didn't understand why we have to do quicklists to take
> advantage of the fact that the pages are in a pristine state when they
> are freed. I thought the whole point of the slab allocator was to be
> able to take advantage of that...
It used
David Miller writes:
> I ported this to sparc64 as per the patch below, tested on
> UP SunBlade1500 and 24 cpu Niagara T1000.
Did you see any performance improvement? We used to have quicklists
on ppc, but I remain to be convinced that they actually help.
Also, I didn't understand why we have
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 18:09:23 -0800 (PST)
> 6 patches follow this message:
>
> [QUICKLIST 1/6] Extract quicklist implementation from IA64
> [QUICKLIST 2/6] i386: quicklist support
> [QUICKLIST 3/6] i386: Use standard list manipulators for pgd_list
>
On Mon, Mar 12, 2007 at 04:12:32AM -0700, Christoph Lameter wrote:
> On Sun, 11 Mar 2007, David Miller wrote:
> > The reason is that every time I've monitored the allocation patterns
> > of these things on SMP, the page table chunks always get released on a
> > different cpu than where they were
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 04:12:32 -0700 (PDT)
> On Sun, 11 Mar 2007, David Miller wrote:
>
> > I'm going to make the radical declaration that it be perhaps often
> > better to always initialize page table chunks to all zeros on
> > allocation.
>
> That
On Sun, 11 Mar 2007, David Miller wrote:
> I'm going to make the radical declaration that it be perhaps often
> better to always initialize page table chunks to all zeros on
> allocation.
That is the case if most of the page is going to be used soon. If we have
sparse access patterns then not
On Sun, 11 Mar 2007, David Miller wrote:
I'm going to make the radical declaration that it be perhaps often
better to always initialize page table chunks to all zeros on
allocation.
That is the case if most of the page is going to be used soon. If we have
sparse access patterns then not
From: Christoph Lameter [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 04:12:32 -0700 (PDT)
On Sun, 11 Mar 2007, David Miller wrote:
I'm going to make the radical declaration that it be perhaps often
better to always initialize page table chunks to all zeros on
allocation.
That is the case
On Mon, Mar 12, 2007 at 04:12:32AM -0700, Christoph Lameter wrote:
On Sun, 11 Mar 2007, David Miller wrote:
The reason is that every time I've monitored the allocation patterns
of these things on SMP, the page table chunks always get released on a
different cpu than where they were
From: Christoph Lameter [EMAIL PROTECTED]
Date: Sat, 10 Mar 2007 18:09:23 -0800 (PST)
6 patches follow this message:
[QUICKLIST 1/6] Extract quicklist implementation from IA64
[QUICKLIST 2/6] i386: quicklist support
[QUICKLIST 3/6] i386: Use standard list manipulators for pgd_list
David Miller writes:
I ported this to sparc64 as per the patch below, tested on
UP SunBlade1500 and 24 cpu Niagara T1000.
Did you see any performance improvement? We used to have quicklists
on ppc, but I remain to be convinced that they actually help.
Also, I didn't understand why we have to
On Tue, 13 Mar 2007, Paul Mackerras wrote:
Also, I didn't understand why we have to do quicklists to take
advantage of the fact that the pages are in a pristine state when they
are freed. I thought the whole point of the slab allocator was to be
able to take advantage of that...
It used to
From: Paul Mackerras [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 11:37:32 +1100
David Miller writes:
I ported this to sparc64 as per the patch below, tested on
UP SunBlade1500 and 24 cpu Niagara T1000.
Did you see any performance improvement? We used to have quicklists
on ppc, but I
From: David Miller [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 19:26:16 -0700 (PDT)
From: Paul Mackerras [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 11:37:32 +1100
David Miller writes:
I ported this to sparc64 as per the patch below, tested on
UP SunBlade1500 and 24 cpu Niagara T1000.
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 18:09:23 -0800 (PST)
> Page table pages have the characteristics that they are typically zero
> or in a known state when they are freed. This is usually the exactly
> same state as needed after allocation. So it makes sense to
From: Christoph Lameter [EMAIL PROTECTED]
Date: Sat, 10 Mar 2007 18:09:23 -0800 (PST)
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed. This is usually the exactly
same state as needed after allocation. So it makes sense to build a
This patchset introduces an arch independent framework to handle lists
of recently used page table pages.
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed. This is usually the exactly
same state as needed after allocation. So it makes
This patchset introduces an arch independent framework to handle lists
of recently used page table pages.
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed. This is usually the exactly
same state as needed after allocation. So it makes
28 matches
Mail list logo
