linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	David Miller <davem@davemloft.net>,
	hugh@veritas.com, jaredeh@gmail.com, cotte@de.ibm.com,
	heiko.carstens@de.ibm.com, linux-arch@vger.kernel.org
Subject: Re: [rfc][patch 2/2] mm: introduce optional pte_special pte bit
Date: Wed, 16 Jan 2008 10:52:41 +0100	[thread overview]
Message-ID: <1200477161.29080.18.camel@localhost> (raw)
In-Reply-To: <20080116054831.GD14049@wotan.suse.de>

On Wed, 2008-01-16 at 06:48 +0100, Nick Piggin wrote:
> On Tue, Jan 15, 2008 at 09:23:57PM -0800, Linus Torvalds wrote:
> > On Tue, 15 Jan 2008, David Miller wrote:
> > >
> > > From: Linus Torvalds <torvalds@linux-foundation.org>
> > > Date: Tue, 15 Jan 2008 20:48:42 -0800 (PST)
> > > 
> > > > Can you give a pointer to some browsable archive?
> > > 
> > > http://marc.info/?l=linux-arch
> > 
> > .. and the discussion itself that actually explains why ARM has problems 
> > and why S390 suddenly _does_ have a bit for this after all?
> > 
> > (Not that I consider marc to be really "browsable" in the first place.. )
> > 
> > 		Linus
> 
> 
> I sent you an exact link to the thread on marc in an earlier message...
> not many others archive linux-arch or linux-mm unfortunately.
> 
> But no I didn't see a discussion of why s390 does have a bit, beyond the
> s390 devs just asserting there is one, and providing a patch ;) I never
> saw any of the discussions concluding that s390 does *not* have a bit
> spare. Do you recall if they were public?

Hmm, it all depends on the type of the pte. The hardware specs tell us
that the last 8 bits of a pte is software defined. There is the hardware
invalid bit 2**9 and the hardware read-only bit 2**10. Two of the
software defined bits and the two hardware bits are used for the page
type. The current code distinguishes 8 different types (the comments
says six but that is wrong :-/):

#define _PAGE_TYPE_EMPTY        0x400
#define _PAGE_TYPE_NONE         0x401
#define _PAGE_TYPE_SWAP         0x403
#define _PAGE_TYPE_FILE         0x601   /* bit 0x002 is used for offset !! */
#define _PAGE_TYPE_RO           0x200
#define _PAGE_TYPE_RW           0x000
#define _PAGE_TYPE_EX_RO        0x202
#define _PAGE_TYPE_EX_RW        0x002

The types where we have no free bits are _PAGE_TYPE_SWAP and
_PAGE_TYPE_FILE. That should be true for all architectures, since any
free bit could be used to increase the allowable size of the swap device
and the file-page offset. For 64 bit we could even make room for another
bit in the swap and file ptes since it won't hurt much to lower the swap
size / file-page offset. For 31 bit the bits are in short supply. In ESA
mode another 3 bits of the pte are reserved, they have to be zero or bad
things will happen (specification exceptions). So with the two hardware
and the two software bits a total of 7 bits of 32 bits are lost. As the
comment for _PAGE_TYPE_FILE indicates I was able to squeeze one more bit
out of a pte for file ptes. Which makes 25 free bits for a swap pte and
26 free bits for a file pte, or 32 4GB swap devices and 64GB max file
size for remap_file_pages. Again this is ONLY for 31 bit and ONLY for
the swap and file ptes. For pte_present() ptes we have 6 free bits.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.



  reply	other threads:[~2008-01-16  9:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13  3:08 [rfc] changes to user memory mapping scheme Nick Piggin
2008-01-13  3:09 ` [rfc][patch 1/2] mm: introduce VM_MIXEDMAP Nick Piggin
2008-01-13  3:10 ` [rfc][patch 2/2] mm: introduce optional pte_special pte bit Nick Piggin
2008-01-13  3:41   ` Linus Torvalds
2008-01-13  4:39     ` Nick Piggin
2008-01-13  4:45       ` Linus Torvalds
2008-01-13  5:06         ` Nick Piggin
2008-01-13 16:50           ` Linus Torvalds
2008-01-13 20:46             ` Martin Schwidefsky
2008-01-14 21:04             ` Jared Hulbert
2008-01-15  9:18               ` Carsten Otte
2008-01-16  3:38             ` Nick Piggin
2008-01-16  4:04               ` Linus Torvalds
2008-01-16  4:37                 ` Nick Piggin
2008-01-16  4:48                   ` Linus Torvalds
2008-01-16  4:51                     ` David Miller
2008-01-16  5:23                       ` Linus Torvalds
2008-01-16  5:48                         ` Nick Piggin
2008-01-16  9:52                           ` Martin Schwidefsky [this message]
2008-01-16  5:17                     ` Nick Piggin
2008-01-16 10:52                       ` Catalin Marinas
2008-01-16 18:18                         ` Russell King
2008-01-16 17:21                       ` Linus Torvalds
2008-01-16 17:14   ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1200477161.29080.18.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hugh@veritas.com \
    --cc=jaredeh@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).