> (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" tothe linear address is quite common, and if "struct page" isn't apower-of-two it gets slow.

> - Instead of having a zone pointer mask use a 8 or 16 byte index into a > zone table. On a modern CPU it is much cheaper to do the and/shifts than> to do even a single cache miss during page aging. On a lot of systems > that zone index could be hardcoded to 0 anyways, giving better code.> - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which> has the same swapping algorithm even only uses 8bit)

This would be good, but can be hard.

FreeBSD doesn't try to be portable any more, but Linux does, and there arearchitectures where 8- and 16-bit accesses aren't atomic but have to bedone with read-modify-write cycles.

And even for fields like "age", where we don't care whether the age itselfis 100% accurate, we _do_ care that the fields close-by don't get strangeeffects from updating "age". We used to have exactly this problem on alphaback in the 2.1.x timeframe.

This is why a lot of fields are 32-bit, even though we wouldn't need morethan 8 or 16 bits of them.

> - Remove the waitqueue debugging (obvious @)

Not obvious enough. There are magic things that could be done, like hidingthe wait-queue lock bit in the waitqueue lists themselves etc. That couldbe done with some per-architecture magic etc.

> - 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.

Only the LSF patches made it 64-bit. That never made it into the standardkernel.

Sure, we could make it "u32" and thus force it to be 32-bit even on 64-bitarchitectures, but some day somebody will want to have more than 46 bitsof file mappings, and which 46 bits is _huge_ on a 32-bit machine, on a64-bit one in 5 years it will not be entirely unreasonable.

Anyway, I don't want to increase "struct page" in size, but I also don'tthink it's worth micro-optimizing some of these things if the code getsharder to maintain (like the partial-word stuff would be).

The biggest win by far would come from increasing the page-size, somethingwe can do even in software. Having a "kernel page size" of 8kB even on x86would basically cut the overhead in half. As that would also improve someother things (like having better throughput due to bigger contiguouschunks), that's something I'd like to see some day.

(And user space wouldn't ever have to know - we could map in "half pages"aka "hardware pages" without mappign the whole page).

Linus

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgPlease read the FAQ at http://www.tux.org/lkml/