On Tue, Apr 05, 2005 at 10:15:18PM -0700, Gerrit Huizenga wrote:
> SpecSDET, Aim7 or ReAim from OSDL are probably what you are thinking of.
SDET isn't publicly available.
I hope by now osdl-reaim is called "osdl-aim7":
http://lkml.org/lkml/2003/8/1/172
grant
-
To unsubscribe from this lis
On Tue, 05 Apr 2005 21:48:22 PDT, David Mosberger wrote:
> > On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter <[EMAIL
> > PROTECTED]> said:
>
> Christoph> Which benchmark would you recommend for this?
>
> I don't know about "recommend", but I think SPECweb, SPECjbb,
> the-UN
> On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter <[EMAIL
> PROTECTED]> said:
Christoph> Which benchmark would you recommend for this?
I don't know about "recommend", but I think SPECweb, SPECjbb,
the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in
general any
On Tue, 5 Apr 2005, David Mosberger wrote:
> What LMbench test other than fork/exec would you have expected to be
> affected by this? LMbench is not a good benchmark for this (remember:
> it's a _micro_ benchmark).
LMbench does a variety of things and I expected to see at least
something on the
> On Tue, 5 Apr 2005 17:15:53 -0700 (PDT), Christoph Lameter <[EMAIL
> PROTECTED]> said:
Christoph> On Thu, 24 Mar 2005, David Mosberger wrote:
>> That's definitely the case. See my earlier post on this topic:
>> http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html
>> Unfor
On Thu, 24 Mar 2005, David Mosberger wrote:
> That's definitely the case. See my earlier post on this topic:
>
> http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html
>
> Unfortunately, nobody reported any results for larger machines and/or
> more interesting workloads, so the patch is in li
On Sun, 27 Mar 2005, Andi Kleen wrote:
> > Clearly, if the CPU that's clearing the page is likely to use that
> > same page soon after, it'd be useful to use temporal stores.
>
> That is always the case in the current code (without Christophers
> pre cleaning daemon). The page fault handler clears
On 27 Mar 2005 19:12:20 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> With non temporal stores
> you guarantee at least one hard cache miss directly after
> the return to user space.
This is true if the cacheline were not present already at
the time of the non-temporal store.
I know what you're
> Clearly, if the CPU that's clearing the page is likely to use that
> same page soon after, it'd be useful to use temporal stores.
That is always the case in the current code (without Christophers
pre cleaning daemon). The page fault handler clears and user space
is guaranteed to need at least o
On Thu, 24 Mar 2005, David S. Miller wrote:
> Erm... were any of your test builds done with the new CONFIG_CLEAR_COLD
> option enabled? :-)
These were all fixed but I failed to do a "quilt refresh" sigh... The
email issues are also fixed now sigh. What a day.
> Next, replace your arch/
On Thu, 24 Mar 2005 14:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Could you help me fix up this patch replacing the old clear_pages patch?
Ok, first you need to mark the order and gfp arguments as unsigned
for mm/page_alloc.c:prep_zero_page() so that it matches the prototype
On Thu, 24 Mar 2005 14:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Thu, 24 Mar 2005, David S. Miller wrote:
>
> > > prep_zero_page would use a temporal clear for an order 0 page but a
> > > nontemporal clear for higher order pages.
> >
> > That sounds about right to me.
>
On Thu, 24 Mar 2005, David S. Miller wrote:
> > prep_zero_page would use a temporal clear for an order 0 page but a
> > nontemporal clear for higher order pages.
>
> That sounds about right to me.
>
> Hmmm, I'm inspired to experiment with this on sparc64 a bit.
Could you help me fix up this patch
On Thu, 24 Mar 2005 10:41:06 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> So it would be useful to have
>
> clear_page-> Temporal. Only zaps one page
>
> and
>
> clear_pages -> Zaps arbitrary order of page non-temporal
>
>
> Rework the clear_pages patch to do just th
On Thu, 24 Mar 2005, David Mosberger wrote:
> That's definitely the case. See my earlier post on this topic:
>
> http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html
>
> Unfortunately, nobody reported any results for larger machines and/or
> more interesting workloads, so the patch is in li
> On Fri, 18 Mar 2005 20:28:08 +0100, Andi Kleen <[EMAIL PROTECTED]> said:
>> stores in general for clearing pages? I checked and Itanium has
>> always used non-temporal stores. So there will be no benefit for
>> us from this
Andi> That is weird. I would actually try to switch to temp
On Friday 18 March 2005 21:28, Andi Kleen wrote:
> On Fri, Mar 18, 2005 at 07:00:06AM -0800, Christoph Lameter wrote:
> > On Fri, 18 Mar 2005, Denis Vlasenko wrote:
> >
> > > NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> > > the fact that zeroed page ends up evicted fr
On Fri, 18 Mar 2005, Andi Kleen wrote:
> It does not make any sense if you think of it - the memory bus
> of the CPU cannot be that much faster than the cache.
The memory bus would be able to reach a higher rate if properly optimized
for sequential writes to memory. A cache typically does random
On Fri, Mar 18, 2005 at 07:00:06AM -0800, Christoph Lameter wrote:
> On Fri, 18 Mar 2005, Denis Vlasenko wrote:
>
> > NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> > the fact that zeroed page ends up evicted from cache. Luckily, this is
> > exactly
> > what you want w
On Fri, 18 Mar 2005, Denis Vlasenko wrote:
> NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> the fact that zeroed page ends up evicted from cache. Luckily, this is exactly
> what you want with prezeroing.
These are pretty significant results. Maybe its best to use non-t
> Andi Kleen (iirc) says that non-temporal stores seem to be
> big win in microbenchmarks (and I second that), but they are
> a net loss when we are going to use zeroed page just after
> zeroing. He recommends avoid using non-temporal stores
The rule of thumb is to only use non temporal stores whe
On Thursday 17 March 2005 03:33, Christoph Lameter wrote:
> On Fri, 11 Mar 2005, Denis Vlasenko wrote:
>
> > Andi Kleen (iirc) says that non-temporal stores seem to be
> > big win in microbenchmarks (and I second that), but they are
> > a net loss when we are going to use zeroed page just after
>
On Fri, 11 Mar 2005, Denis Vlasenko wrote:
> Andi Kleen (iirc) says that non-temporal stores seem to be
> big win in microbenchmarks (and I second that), but they are
> a net loss when we are going to use zeroed page just after
> zeroing. He recommends avoid using non-temporal stores
>
> With this
On Friday 11 March 2005 03:03, Christoph Lameter wrote:
> Changelog:
> - use Kconfig and CONFIG_CLEAR_PAGES
>
> The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c
> may benefit from a
> clear_page that is capable of zeroing multiple pages at once. The following
> patch a
Changelog:
- use Kconfig and CONFIG_CLEAR_PAGES
The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c may
benefit from a
clear_page that is capable of zeroing multiple pages at once. The following
patch adds
a function "clear_pages" that is capable of clearing multiple cont
On Thu, 10 Mar 2005, Dave Hansen wrote:
> > +extern void clear_pages (void *page, int order);
> > extern void copy_page (void *to, void *from);
> > +#define clear_page(__page) clear_pages(__page, 0)
> > +#define __HAVE_ARCH_CLEAR_PAGES
>
> Although this is a simple instance, could this please be
On Thu, 2005-03-10 at 12:35 -0800, Christoph Lameter wrote:
> +#ifdef __HAVE_ARCH_CLEAR_PAGES
> + if (!PageHighMem(page)) {
> + clear_pages(page_address(page), order);
> + return;
> + }
> +#endif
> +
> for(i = 0; i < (1 << order); i++)
> clear_hig
27 matches
Mail list logo
