On Tue, 20 Mar 2007, Paul Mackerras wrote:
> Christoph Lameter writes:
>
> > +static inline void *quicklist_alloc(int nr, gfp_t flags, void (*ctor)(void
> > *))
> > +{
>
> ...
>
> > + p = (void *)__get_free_page(flags | __GFP_ZERO);
>
> This will cause problems on 64-bit powerpc, at least
On Mon, 19 Mar 2007, Andrew Morton wrote:
> Yes, a common quicklist implementation is good. But no quicklist
> implementation at all is better. You say that will be slower, and you may
> well be right, but I say let's demonstrate that (please) rather than
> speculating.
There are at least 3
On Mon, 19 Mar 2007, Andrew Morton wrote:
Yes, a common quicklist implementation is good. But no quicklist
implementation at all is better. You say that will be slower, and you may
well be right, but I say let's demonstrate that (please) rather than
speculating.
There are at least 3 arches
On Tue, 20 Mar 2007, Paul Mackerras wrote:
Christoph Lameter writes:
+static inline void *quicklist_alloc(int nr, gfp_t flags, void (*ctor)(void
*))
+{
...
+ p = (void *)__get_free_page(flags | __GFP_ZERO);
This will cause problems on 64-bit powerpc, at least with 4k pages,
Christoph Lameter writes:
> +static inline void *quicklist_alloc(int nr, gfp_t flags, void (*ctor)(void
> *))
> +{
...
> + p = (void *)__get_free_page(flags | __GFP_ZERO);
This will cause problems on 64-bit powerpc, at least with 4k pages,
since the pmd and pgd levels only use 1/4 of a
On Mon, 19 Mar 2007 18:03:54 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Mon, 19 Mar 2007, Andrew Morton wrote:
>
> > > See the patch. We are only touching 2 cachelines instead of 32. So even
> > > without considering the page allocator overhead and the slab allocator
> > >
On Mon, 19 Mar 2007, Andrew Morton wrote:
> > +
> > +#ifdef CONFIG_QUICKLIST
> > +
> > +#ifndef CONFIG_NR_QUICK
> > +#define CONFIG_NR_QUICK 1
> > +#endif
>
> No, please don't define config items like this. Do it in Kconfig.
They can be set up in the arch specific Kconfig. Ok. I moved the
On Mon, 19 Mar 2007, Andrew Morton wrote:
> > See the patch. We are only touching 2 cachelines instead of 32. So even
> > without considering the page allocator overhead and the slab allocator
> > overhead (which will make the situation even better) its superior.
>
> That's not proof, it is
On Mon, 19 Mar 2007 17:44:28 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Mar 2007, Andrew Morton wrote:
>
> > Please provide proof that quicklists are superior to simply going direct to
> > the page allocator for these pages.
>
> See the patch. We are only touching 2
On Mon, 19 Mar 2007, Andrew Morton wrote:
> Please provide proof that quicklists are superior to simply going direct to
> the page allocator for these pages.
See the patch. We are only touching 2 cachelines instead of 32. So even
without considering the page allocator overhead and the slab
On Mon, 19 Mar 2007 15:37:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> ...
>
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-2.6.21-rc3-mm2/include/linux/quicklist.h2007-03-16
> 02:19:15.0 -0700
> @@ -0,0 +1,95 @@
> +#ifndef LINUX_QUICKLIST_H
>
On Mon, 19 Mar 2007 16:57:55 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Mar 2007, Andrew Morton wrote:
>
> > Has it been proven that quicklists are superior to simply going direct to
> > the
> > page allocator for these pages?
>
> Yes.
Sigh.
Please provide proof
On Mon, 19 Mar 2007, Andrew Morton wrote:
> Has it been proven that quicklists are superior to simply going direct to the
> page allocator for these pages?
Yes.
> Would it provide a superior solution if we were to a) stop zeroing out the
> pte's when doing a fullmm==1 teardown and b) go direct
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 19 Mar 2007 16:53:29 -0700
> Would it provide a superior solution if we were to a) stop zeroing out the
> pte's when doing a fullmm==1 teardown and b) go direct to the page allocator
> for these pages?
While you could avoid zero'ing them out,
On Mon, 19 Mar 2007 15:37:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> This patchset introduces an arch independent framework to handle lists
> of recently used page table pages to replace the existing (ab)use of the
> slab for that purpose.
>
> 1. Proven code from the IA64
Quicklists for page table pages V3
V2->V3
- Fix Kconfig issues by setting CONFIG_QUICKLIST explicitly
and default to one quicklist if NR_QUICK is not set.
- Fix i386 support. (Cannot mix PMD and PTE allocs.)
- Discussion of V2.
http://marc.info/?l=linux-kernel=117391339914767=2
V1->V2
- Add
Quicklists for page table pages V3
V2-V3
- Fix Kconfig issues by setting CONFIG_QUICKLIST explicitly
and default to one quicklist if NR_QUICK is not set.
- Fix i386 support. (Cannot mix PMD and PTE allocs.)
- Discussion of V2.
http://marc.info/?l=linux-kernelm=117391339914767w=2
V1-V2
- Add
On Mon, 19 Mar 2007 15:37:16 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
This patchset introduces an arch independent framework to handle lists
of recently used page table pages to replace the existing (ab)use of the
slab for that purpose.
1. Proven code from the IA64 arch.
Has
On Mon, 19 Mar 2007, Andrew Morton wrote:
Has it been proven that quicklists are superior to simply going direct to the
page allocator for these pages?
Yes.
Would it provide a superior solution if we were to a) stop zeroing out the
pte's when doing a fullmm==1 teardown and b) go direct to
From: Andrew Morton [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 16:53:29 -0700
Would it provide a superior solution if we were to a) stop zeroing out the
pte's when doing a fullmm==1 teardown and b) go direct to the page allocator
for these pages?
While you could avoid zero'ing them out, you
On Mon, 19 Mar 2007 16:57:55 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 19 Mar 2007, Andrew Morton wrote:
Has it been proven that quicklists are superior to simply going direct to
the
page allocator for these pages?
Yes.
Sigh.
Please provide proof that
On Mon, 19 Mar 2007 15:37:16 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
...
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21-rc3-mm2/include/linux/quicklist.h2007-03-16
02:19:15.0 -0700
@@ -0,0 +1,95 @@
+#ifndef LINUX_QUICKLIST_H
+#define
On Mon, 19 Mar 2007, Andrew Morton wrote:
Please provide proof that quicklists are superior to simply going direct to
the page allocator for these pages.
See the patch. We are only touching 2 cachelines instead of 32. So even
without considering the page allocator overhead and the slab
On Mon, 19 Mar 2007 17:44:28 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 19 Mar 2007, Andrew Morton wrote:
Please provide proof that quicklists are superior to simply going direct to
the page allocator for these pages.
See the patch. We are only touching 2 cachelines
On Mon, 19 Mar 2007, Andrew Morton wrote:
See the patch. We are only touching 2 cachelines instead of 32. So even
without considering the page allocator overhead and the slab allocator
overhead (which will make the situation even better) its superior.
That's not proof, it is
On Mon, 19 Mar 2007, Andrew Morton wrote:
+
+#ifdef CONFIG_QUICKLIST
+
+#ifndef CONFIG_NR_QUICK
+#define CONFIG_NR_QUICK 1
+#endif
No, please don't define config items like this. Do it in Kconfig.
They can be set up in the arch specific Kconfig. Ok. I moved the
#ifndef .. #endif
On Mon, 19 Mar 2007 18:03:54 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Mon, 19 Mar 2007, Andrew Morton wrote:
See the patch. We are only touching 2 cachelines instead of 32. So even
without considering the page allocator overhead and the slab allocator
overhead
Christoph Lameter writes:
+static inline void *quicklist_alloc(int nr, gfp_t flags, void (*ctor)(void
*))
+{
...
+ p = (void *)__get_free_page(flags | __GFP_ZERO);
This will cause problems on 64-bit powerpc, at least with 4k pages,
since the pmd and pgd levels only use 1/4 of a page.
28 matches
Mail list logo
