On Tue, 2006-06-06 at 09:32 -0700, Christoph Lameter wrote:
> > Whether it's correct depends on what Martin was trying to achieve
> > with his test. I'm surprised to find a very ordinary
> > #define __swp_type(entry) (((entry).val >> 2) & 0x1f)
> > in include/asm-s390/pgtable.h, and no architecture with a more
> > limiting mask.
>
> Yes we need to hear from Martin.
s390 supports up to 32 swap devices. At the same time on 31 bit systems
only up to 4GB of swap is supported per device. That is because there
are three reserved bits in the 31 bit pte, (pte & 0x80000900) must be
zero. Bit 2^10 is the invalid bit, bit 2^9 the read-only bit. Two more
bits are needed to distinguish between the different pte types. That
makes 32-7 = 25 bits in total for offset and swap device. 5 bits are
used for the swap device number, and 20 for the offset.
I have chosen this split because for 31 the bit systems in 1999 the
standard dasd device has been a model 3 with a capacity of 2.6 GB.
So much for the history lesson.
> > Not really (though the clarity and reassurance of the additional
> > MAX_SWAPFILES test is good). We went over it a year or two back,
> > and the macro contortions do involve MAX_SWAPFILES_SHIFT: which
> > up to and including 2.6.17 has enforced the MAX_SWAPFILES limit.
>
> It looks though as if the testers were able to define more than 32 swap
> devices. So there is the danger of overwriting the memory
> following the swap info if we do not fix this.
>
> Where are the macro contortions? No arch uses MAX_SWAPFILES_SHIFT for its
> definitions and the only other significant use is in swapops.h to
> determine the shift.
swp_type(pte_to_swp_entry(swp_entry_to_pte(swp_entry(~0UL,0))))
evaluates to 31 for s390. The idea has been that the creation of a swap
entry with ~0UL as the type should mask off all bits that can not be
represented in a swap entry. Convert it back and you have the maximum
number of swap devices. That should be true for all architectures.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
