Messages in this thread |  | | Date | Fri, 29 Dec 2000 00:25:27 +0100 | From | Andi Kleen <> | Subject | Re: test13-pre5 |
| |
On Thu, Dec 28, 2000 at 03:15:01PM -0800, Linus Torvalds wrote: > > (first number for 32bit, second for 64bit) > > > > - Do not compile virtual in when the kernel does not support highmem > > (saves 4/8 bytes) > > Even on UP, "virtual" often helps. The conversion from "struct page" to > the linear address is quite common, and if "struct page" isn't a > power-of-two it gets slow.
Are you sure? Last time I checked gcc did a very good job at optimizing small divisions with small integers, without using div. It just has to be a good integer with not too many set bits.
> is 100% accurate, we _do_ care that the fields close-by don't get strange > effects from updating "age". We used to have exactly this problem on alpha > back in the 2.1.x timeframe.
When it is shared with a constant field (like zone index) it shouldn't matter, no ? At worst you can see outdated data, and when the outdated data is constant all is fine.
> > - flags can be __u32 on 64bit hosts, sharing 64bit with something that > > is tolerant to async updates (e.g. the zone table index or the index) > > - index could be probably u32 instead of unsigned long, saving 4 bytes > > on i386 > > It already _is_ 32-bit on x86.
Oops. It was a typo. I meant to write "saving 4 bytes on 64bit"
> Anyway, I don't want to increase "struct page" in size, but I also don't > think it's worth micro-optimizing some of these things if the code gets > harder to maintain (like the partial-word stuff would be).
Ok pity :-/
Hopefully all the "goto out" micro optimizations can be taken out then too, I recently found out that gcc 2.97's block moving pass has the tendency to move the outlined blocks inline again ;)
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |