On Mon, 2008-02-25 at 13:09 +0100, Hans Rosenfeld wrote:
> On Sat, Feb 23, 2008 at 10:31:01AM -0800, Dave Hansen wrote:
> > > > - 4 bits for the page size, with 0 meaning native page size (4k on x86,
> > > > 8k on alpha, ...) and values 1-15 being specific to the architecture
> > > > (I used
On Sat, Feb 23, 2008 at 10:31:01AM -0800, Dave Hansen wrote:
> > > - 4 bits for the page size, with 0 meaning native page size (4k on x86,
> > > 8k on alpha, ...) and values 1-15 being specific to the architecture
> > > (I used 1 for 2M, 2 for 4M and 3 for 1G for x86)
>
> "Native page size"
On Sat, Feb 23, 2008 at 10:31:01AM -0800, Dave Hansen wrote:
- 4 bits for the page size, with 0 meaning native page size (4k on x86,
8k on alpha, ...) and values 1-15 being specific to the architecture
(I used 1 for 2M, 2 for 4M and 3 for 1G for x86)
Native page size probably a bad
On Mon, 2008-02-25 at 13:09 +0100, Hans Rosenfeld wrote:
On Sat, Feb 23, 2008 at 10:31:01AM -0800, Dave Hansen wrote:
- 4 bits for the page size, with 0 meaning native page size (4k on x86,
8k on alpha, ...) and values 1-15 being specific to the architecture
(I used 1 for 2M, 2
On Sat, 2008-02-23 at 10:18 +0800, Matt Mackall wrote:
> Another
> > problem is that there is no way to get information about the page size a
> > specific mapping uses.
Is this true generically, or just with pagemap? It seems like we should
have a way to tell that a particular mapping is of
On Sat, 2008-02-23 at 00:06 -0800, Andrew Morton wrote:
> On Wed, 20 Feb 2008 14:57:43 +0100 "Hans Rosenfeld" <[EMAIL PROTECTED]> wrote:
>
> > The current code for /proc/pid/pagemap does not work with huge pages (on
> > x86). The code will make no difference between a normal pmd and a huge
> >
On Wed, 20 Feb 2008 14:57:43 +0100 "Hans Rosenfeld" <[EMAIL PROTECTED]> wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page as ptes.
On Wed, 20 Feb 2008 14:57:43 +0100 Hans Rosenfeld [EMAIL PROTECTED] wrote:
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd, trying to parse the contents of the huge page as ptes. Another
On Sat, 2008-02-23 at 00:06 -0800, Andrew Morton wrote:
On Wed, 20 Feb 2008 14:57:43 +0100 Hans Rosenfeld [EMAIL PROTECTED] wrote:
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd,
On Sat, 2008-02-23 at 10:18 +0800, Matt Mackall wrote:
Another
problem is that there is no way to get information about the page size a
specific mapping uses.
Is this true generically, or just with pagemap? It seems like we should
have a way to tell that a particular mapping is of large
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd, trying to parse the contents of the huge page as
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd, trying to parse the contents of the huge page as ptes. Another
problem is that there is no way to get information about the page size a
specific
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd, trying to parse the contents of the huge page as ptes. Another
problem is that there is no way to get information about the page size a
specific
14 matches
Mail list logo
