shrink per_cpu_pages to fit 32byte cacheline

PATCH In review Marcelo Tosatti 3 participants 9 messages Sep 13, 2004 – Sep 15, 2004

Subsystems (3)

Memory management MM core MGLRU

lore

Share & tools

lore

Marcelo Tosatti

author

2004-09-13 23:38 UTC #0 lore raw

PATCH 1/1 shrink per_cpu_pages to fit 32byte cacheline

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.

The counters never reach 2 ^ 16 (the maximum "batch" can get is 64).

Please apply

include/linux/mmzone.h renamed from include/linux/mmzone.h.orig +4 -4

@@ -43,10 +43,10 @@
 #endif
 
 struct per_cpu_pages {
-	int count;		/* number of pages in the list */
-	int low;		/* low watermark, refill needed */
-	int high;		/* high watermark, emptying needed */
-	int batch;		/* chunk size for buddy add/remove */
+	short int count;		/* number of pages in the list */
+	short int low;		/* low watermark, refill needed */
+	short int high;		/* high watermark, emptying needed */
+	short int batch;		/* chunk size for buddy add/remove */
 	struct list_head list;	/* the list of pages */
 };

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arjan van de Ven

2004-09-14 06:10 UTC #1 lore raw

Quoted 4 lines · Marcelo Tosatti

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)

Marcelo Tosatti

author

2004-09-14 09:34 UTC #2 lore raw

Quoted 9 lines · Arjan van de Ven

Quoted 4 lines · Marcelo Tosatti
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arjan van de Ven

2004-09-14 11:13 UTC #3 lore raw

Quoted 1 line · Marcelo Tosatti

How come short access can cost 1 extra cycle? Because you need two "read bytes" ?

on an x86, a word (2byte) access will cause a prefix byte to the instruction, that particular prefix byte will take an extra cycle during execution of the instruction and potentially reduces the parallal decodability of instructions....

Marcelo Tosatti

author

2004-09-14 10:01 UTC #4 lore raw

Quoted 7 lines · Arjan van de Ven

Quoted 1 line · Marcelo Tosatti
How come short access can cost 1 extra cycle? Because you need two "read bytes" ?
on an x86, a word (2byte) access will cause a prefix byte to the instruction, that particular prefix byte will take an extra cycle during execution of the instruction and potentially reduces the parallal decodability of instructions....

OK thanks Arjan, where did you read this? The "Intel IA32 Optimization Guide" ?

Thanks for the info.

Andrew, we might want to revert the pagevec shrinkage part which changes couple of variables to short - want to keep the "15" though.

Arjan van de Ven

2004-09-14 11:44 UTC #5 lore raw

Quoted 10 lines · Marcelo Tosatti

Quoted 7 lines · Arjan van de Ven
Quoted 1 line · Marcelo Tosatti
How come short access can cost 1 extra cycle? Because you need two "read bytes" ?
on an x86, a word (2byte) access will cause a prefix byte to the instruction, that particular prefix byte will take an extra cycle during execution of the instruction and potentially reduces the parallal decodability of instructions....
OK thanks Arjan, where did you read this? The "Intel IA32 Optimization Guide" ?

some version of that; I can't find it in my current one though. Hrmpf Maybe there's someone from intel or amd on this list who can confirm the performance impact of the 0x66 operand size override prefix

Marcelo Tosatti

author

2004-09-14 22:45 UTC #6 lore raw

Quoted 10 lines · Arjan van de Ven

Quoted 9 lines · Marcelo Tosatti
Quoted 7 lines · Arjan van de Ven
Quoted 1 line · Marcelo Tosatti
How come short access can cost 1 extra cycle? Because you need two "read bytes" ?
on an x86, a word (2byte) access will cause a prefix byte to the instruction, that particular prefix byte will take an extra cycle during execution of the instruction and potentially reduces the parallal decodability of instructions....

Quoted 5 lines

Quoted 1 line
OK thanks Arjan, where did you read this? The "Intel IA32 Optimization Guide" ?
some version of that; I can't find it in my current one though. Hrmpf Maybe there's someone from intel or amd on this list who can confirm the performance impact of the 0x66 operand size override prefix

Prefix "data16" I see... Well it doesnt seem anyone really familiar with this is part of the list - who you think would be sure about this?

Jun Nakajima maybe?

We need to be sure because we've just done for pagevec's. --
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Nick Piggin

2004-09-15 00:57 UTC #7 lore raw

Quoted 10 lines · Marcelo Tosatti

Quoted 3 lines
some version of that; I can't find it in my current one though. Hrmpf Maybe there's someone from intel or amd on this list who can confirm the performance impact of the 0x66 operand size override prefix
Prefix "data16" I see... Well it doesnt seem anyone really familiar with this is part of the list - who you think would be sure about this?
Jun Nakajima maybe?
We need to be sure because we've just done for pagevec's.

You could leave them as ints, and just make the size of the pagevec 14 on 32-bit archs and 15 on 64-bit ones.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Marcelo Tosatti

author

2004-09-15 00:48 UTC #8 lore raw

Quoted 10 lines · Nick Piggin

Quoted 8 lines · Marcelo Tosatti
Quoted 3 lines
some version of that; I can't find it in my current one though. Hrmpf Maybe there's someone from intel or amd on this list who can confirm the performance impact of the 0x66 operand size override prefix
Prefix "data16" I see... Well it doesnt seem anyone really familiar with this is part of the list - who you think would be sure about this?

Quoted 6 lines

Quoted 3 lines
Jun Nakajima maybe?
We need to be sure because we've just done for pagevec's.
You could leave them as ints, and just make the size of the pagevec 14 on 32-bit archs and 15 on 64-bit ones.

Indeed!