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
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 list:
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,
>
> 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
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
>>
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
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 limbo
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
Unfortunately, nobody
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: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 anything that
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,
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
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 and
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
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
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
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
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
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
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
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
> 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
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 temporal
Andi
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 limbo
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 that? Maybe
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 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.
Hmmm, I'm
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, 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
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
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 from cache.
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
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
> 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
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 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
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 when
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
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 with
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, 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
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 new
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
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 adds
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
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++)
>
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 continuous pages
at once.
This used to be part of
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 continuous pages
at once.
This used to be part of
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_highpage(page
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 done in 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
56 matches
Mail list logo
