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 allocators
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 effe
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 per
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 pertin
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
* 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 anyt
* 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, pg
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 graph
* 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 Wrigh
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 thing
* 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 rem
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
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 t
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 n
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 t
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 t
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 noti
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 ra
22 matches
Mail list logo
