Re: [PATCH] add a clear_pages function to clear pages of higher order

From: Andi Kleen <ak_at_muc.de>
Date: 2005-03-19 06:28:08
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 prezeroing.
> 
> These are pretty significant results. Maybe its best to use non-temporal

The differences are actually less. I do not know what Denis benchmarked,
but in my tests the difference was never more than ~10%.  He got a zero
too much? 

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.

And the drawback of eating the cache misses later is really very
significant.

> 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

That is weird. I would actually try to switch to temporal stores, maybe
it will improve some benchmarks. 

> approach (we have 16k and 64k page sizes which may make the situation a
> bit different). Try to update the i386 architectures to do the same?

Definitely not. 

You can experiment with using it for the cleaner daemon, but even
there I would use some heuristic to make sure you only use it 
on a page that are at the end of a pretty long queue.

e.g. if you can guarantee that the page allocator will go through
500k-1MB before going to the NT page that is cache cold it may
be a good idea. But that might be pretty complicated and I am not
sure it will be worth it.

But for the clear running in the page fault handler context it is 
definitely a bad idea.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Mar 18 14:29:14 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:37 EST