On Tue, Sep 14, 2004 at 08:10:04AM +0200, Arjan van de Ven wrote:

On Tue, 2004-09-14 at 01:38, Marcelo Tosatti wrote:

quoted

Subject says it all, the following patch shrinks per_cpu_pages
struct from 24 to 16bytes, that makes the per CPU array containing
hot and cold "per_cpu_pages[2]" fit on 32byte cacheline. This structure
is often used so I bet this is a useful optimization.

I'm not sure it's worth it. cachelines are 64 or 128 bytes nowadays and
a short access costs you at least 1 extra cycle per access on several
x86 cpus (byte and dword are cheap, short is not)

I changed the counters to short thinking about 32 byte cacheline machines.  

There are a lot of non-x86 boxes which have 32 byte cachelines (embedded) and which 
will continue to have such AFAIK.

How come short access can cost 1 extra cycle? Because you need two "read bytes" ?
It doesnt make much sense to me. I should go look into gcc asm output.

If that's true we should also undo the pagevec shrinking which went into -mm5.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>