On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
> Tried this also on x86_64 with an enhanced quicklist patch that also deals
> with ptes (at the price of not guaranteeing the free after the tlb flush):
...
> Seems that there is a slight benefit but its also barely above noise
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> NIH == "Not Invented Here." Basically a sort of idea theft, often used
> to grab credit for patches. You're not the one involved there. That was
> a digression. One could say, though, that a solution to the slab issues
> is to NIH slab
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
>>> No that was described in the patch. Quote:
>>> "i386 only provides support for caching constructed pgd and pmds. These
>>> are comparatively rare to ptes so it is no surprise that the current
>>> approach has only minimal
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
>> As far as kernel compiles being relevant to anything besides
>> potentially optimizing a particular major benchmark using gcc as one
>> of its components... yeah, right. It's too macro to be a microbenchmark
>> of anything and too micro to be
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> As far as kernel compiles being relevant to anything besides
> potentially optimizing a particular major benchmark using gcc as one
> of its components... yeah, right. It's too macro to be a microbenchmark
> of anything and too micro to be
On Wed, 28 Mar 2007 15:01:31 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
> > No that was described in the patch. Quote:
> > "i386 only provides support for caching constructed pgd and pmds. These
> > are
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> William Lee Irwin III wrote:
> >>clone_pgd_range() for consistency? and it seems we lost a
> >>paravirt_alloc_pd_clone() in there somewhere.
> >>
> >
> >Yes, another reason why it shouldn't have been posted as-is. It was not
> >intended to for
* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
> * Christoph Lameter ([EMAIL PROTECTED]) wrote:
> >> +#ifdef CONFIG_HIGHMEM64G
> >> +#define __pgd_alloc() kmem_cache_alloc(pgd_cache,
> >> GFP_KERNEL|__GFP_REPEAT)
> >> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache,
William Lee Irwin III wrote:
clone_pgd_range() for consistency? and it seems we lost a
paravirt_alloc_pd_clone() in there somewhere.
Yes, another reason why it shouldn't have been posted as-is. It was not
intended to for anything more than comparative benchmarking on systems
without
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
>> +#ifdef CONFIG_HIGHMEM64G
>> +#define __pgd_alloc() kmem_cache_alloc(pgd_cache,
>> GFP_KERNEL|__GFP_REPEAT)
>> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
>> I already went over the methodological issues with kernel compiles.
>> You may be able to prove this, but not this way.
On Wed, Mar 28, 2007 at 02:20:20PM -0700, Christoph Lameter wrote:
> But this way is an established kernel way of doing
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> +#ifdef CONFIG_HIGHMEM64G
> +#define __pgd_alloc()kmem_cache_alloc(pgd_cache,
> GFP_KERNEL|__GFP_REPEAT)
> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
I must've glazed over something, I thought this was
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
> > No that was described in the patch. Quote:
> > "i386 only provides support for caching constructed pgd and pmds. These
> > are comparatively rare to ptes so it is no
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
> No that was described in the patch. Quote:
> "i386 only provides support for caching constructed pgd and pmds. These
> are comparatively rare to ptes so it is no surprise that the current
> approach has only minimal effect.
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> I'd also appreciate if it were mentioned who actually wrote this, given
> that the patch posted was what I sent you verbatim (and actually
> requested you not post for good reasons, some centering around pageattr.c).
Ughhh. Sorry I had this in
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
>> Getting the relevant results without tremendous amounts of noise from
>> other kernel activity needs something like lmbench's fault and fork()
>> microbenchmarks. Also, /proc/profile and/or oprofile results would be
>> useful here to get useful
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
> > Seems that there is a slight benefit but its also barely above noise
> > level.
>
> I already went over the methodological issues with kernel compiles.
> You may be able to
[... kernel compile garbage snipped ...]
On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
> Seems that there is a slight benefit but its also barely above noise
> level.
I already went over the methodological issues with kernel compiles.
You may be able to prove this, but not
On Wed, 28 Mar 2007, Andrew Morton wrote:
> I would like to test qlhack on ia64, because ia64 puts pte-pages into the
> quicklists as well, but my ia64 machine is presently indisposed.
Its probably easier to set the number of cached pages to one.
> My (much) preferred way to handle all this is
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> Getting the relevant results without tremendous amounts of noise from
> other kernel activity needs something like lmbench's fault and fork()
> microbenchmarks. Also, /proc/profile and/or oprofile results would be
> useful here to get useful
On Wed, Mar 28, 2007 at 01:12:56PM -0700, Christoph Lameter wrote:
> The benefit of preconstructed pgds and pmds in the i386 arch code seem to
> be debatable. The performance measurements indicate that there may be a slight
> benefit but it seems to almost vanish in the noise ratio.
> Method used
On Wed, 28 Mar 2007 13:12:56 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> The benefit of preconstructed pgds and pmds in the i386 arch code seem to
> be debatable. The performance measurements indicate that there may be a slight
> benefit but it seems to almost vanish in the noise
The benefit of preconstructed pgds and pmds in the i386 arch code seem to
be debatable. The performance measurements indicate that there may be a slight
benefit but it seems to almost vanish in the noise ratio.
Method used (i386 1G memory):
1. Boot kernel
2. make clean
3. time make all
Results:
The benefit of preconstructed pgds and pmds in the i386 arch code seem to
be debatable. The performance measurements indicate that there may be a slight
benefit but it seems to almost vanish in the noise ratio.
Method used (i386 1G memory):
1. Boot kernel
2. make clean
3. time make all
Results:
On Wed, 28 Mar 2007 13:12:56 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
The benefit of preconstructed pgds and pmds in the i386 arch code seem to
be debatable. The performance measurements indicate that there may be a slight
benefit but it seems to almost vanish in the noise ratio.
On Wed, Mar 28, 2007 at 01:12:56PM -0700, Christoph Lameter wrote:
The benefit of preconstructed pgds and pmds in the i386 arch code seem to
be debatable. The performance measurements indicate that there may be a slight
benefit but it seems to almost vanish in the noise ratio.
Method used
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
Getting the relevant results without tremendous amounts of noise from
other kernel activity needs something like lmbench's fault and fork()
microbenchmarks. Also, /proc/profile and/or oprofile results would be
useful here to get useful notions
On Wed, 28 Mar 2007, Andrew Morton wrote:
I would like to test qlhack on ia64, because ia64 puts pte-pages into the
quicklists as well, but my ia64 machine is presently indisposed.
Its probably easier to set the number of cached pages to one.
My (much) preferred way to handle all this is to
[... kernel compile garbage snipped ...]
On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
Seems that there is a slight benefit but its also barely above noise
level.
I already went over the methodological issues with kernel compiles.
You may be able to prove this, but not
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
Seems that there is a slight benefit but its also barely above noise
level.
I already went over the methodological issues with kernel compiles.
You may be able to prove
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
Getting the relevant results without tremendous amounts of noise from
other kernel activity needs something like lmbench's fault and fork()
microbenchmarks. Also, /proc/profile and/or oprofile results would be
useful here to get useful notions
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
I'd also appreciate if it were mentioned who actually wrote this, given
that the patch posted was what I sent you verbatim (and actually
requested you not post for good reasons, some centering around pageattr.c).
Ughhh. Sorry I had this in
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
No that was described in the patch. Quote:
i386 only provides support for caching constructed pgd and pmds. These
are comparatively rare to ptes so it is no surprise that the current
approach has only minimal effect.
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
No that was described in the patch. Quote:
i386 only provides support for caching constructed pgd and pmds. These
are comparatively rare to ptes so it is no surprise that
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
+#ifdef CONFIG_HIGHMEM64G
+#define __pgd_alloc()kmem_cache_alloc(pgd_cache,
GFP_KERNEL|__GFP_REPEAT)
+#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
I must've glazed over something, I thought this was
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
+#ifdef CONFIG_HIGHMEM64G
+#define __pgd_alloc() kmem_cache_alloc(pgd_cache,
GFP_KERNEL|__GFP_REPEAT)
+#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris Wright
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
I already went over the methodological issues with kernel compiles.
You may be able to prove this, but not this way.
On Wed, Mar 28, 2007 at 02:20:20PM -0700, Christoph Lameter wrote:
But this way is an established kernel way of doing things.
William Lee Irwin III wrote:
clone_pgd_range() for consistency? and it seems we lost a
paravirt_alloc_pd_clone() in there somewhere.
Yes, another reason why it shouldn't have been posted as-is. It was not
intended to for anything more than comparative benchmarking on systems
without
* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
+#ifdef CONFIG_HIGHMEM64G
+#define __pgd_alloc() kmem_cache_alloc(pgd_cache,
GFP_KERNEL|__GFP_REPEAT)
+#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
On
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
William Lee Irwin III wrote:
clone_pgd_range() for consistency? and it seems we lost a
paravirt_alloc_pd_clone() in there somewhere.
Yes, another reason why it shouldn't have been posted as-is. It was not
intended to for anything more than
On Wed, 28 Mar 2007 15:01:31 -0700
William Lee Irwin III [EMAIL PROTECTED] wrote:
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
No that was described in the patch. Quote:
i386 only provides support for caching constructed pgd and pmds. These
are comparatively rare to
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
As far as kernel compiles being relevant to anything besides
potentially optimizing a particular major benchmark using gcc as one
of its components... yeah, right. It's too macro to be a microbenchmark
of anything and too micro to be pertinent
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
As far as kernel compiles being relevant to anything besides
potentially optimizing a particular major benchmark using gcc as one
of its components... yeah, right. It's too macro to be a microbenchmark
of anything and too micro to be pertinent
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
No that was described in the patch. Quote:
i386 only provides support for caching constructed pgd and pmds. These
are comparatively rare to ptes so it is no surprise that the current
approach has only minimal effect.
On
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
NIH == Not Invented Here. Basically a sort of idea theft, often used
to grab credit for patches. You're not the one involved there. That was
a digression. One could say, though, that a solution to the slab issues
is to NIH slab allocators e.g.
On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
Tried this also on x86_64 with an enhanced quicklist patch that also deals
with ptes (at the price of not guaranteeing the free after the tlb flush):
...
Seems that there is a slight benefit but its also barely above noise
46 matches
Mail list logo
