Anton Blanchard wrote:
Hi,
The advantage would be that it wouldn't require a v3 for platforms for
which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
percentage of systems.
You still have to look for the darn magic in two places, so there is no
reason for it to be different.
Hi,
> The advantage would be that it wouldn't require a v3 for platforms for
> which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
> percentage of systems.
>
> You still have to look for the darn magic in two places, so there is no
> reason for it to be different.
The problem
Hi,
The advantage would be that it wouldn't require a v3 for platforms for
which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
percentage of systems.
You still have to look for the darn magic in two places, so there is no
reason for it to be different.
The problem is if
Anton Blanchard wrote:
Hi,
The advantage would be that it wouldn't require a v3 for platforms for
which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
percentage of systems.
You still have to look for the darn magic in two places, so there is no
reason for it to be different.
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Avi Kivity wrote:
>>>
>>> It definitely should, especially on x86-64, where the page size isn't
>>> guaranteed by the ABI (on i386, the ABI guarantees a 4K page size; on x86-64
>>> it can be up to 64K.)
>>
>> Wouldn't that be ia64?
>
> No, the x86-64
H. Peter Anvin [EMAIL PROTECTED] writes:
Avi Kivity wrote:
It definitely should, especially on x86-64, where the page size isn't
guaranteed by the ABI (on i386, the ABI guarantees a 4K page size; on x86-64
it can be up to 64K.)
Wouldn't that be ia64?
No, the x86-64 EFI ABI permits page
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:31:05 -0800
> The advantage would be that it wouldn't require a v3 for platforms for
> which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
> percentage of systems.
>
> You still have to look for the darn magic
David Miller wrote:
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:18:28 -0800
Anton Blanchard wrote:
The other option is to create a v3 swap format that doesnt use any
PAGE_SIZE parameters.
The best thing to do would be to look for the magic both at PAGE_SIZE
(for
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:18:28 -0800
> Anton Blanchard wrote:
> > The other option is to create a v3 swap format that doesnt use any
> > PAGE_SIZE parameters.
>
> The best thing to do would be to look for the magic both at PAGE_SIZE
> (for
Anton Blanchard wrote:
Hi,
I might be missing something but doesn't this break every
SWAP partition that was created with something other than
MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the
Hi,
> I might be missing something but doesn't this break every
> SWAP partition that was created with something other than
> MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the page size :)
The
Anton Blanchard wrote:
2. The badblocks stuff is PAGE_SIZEd too. Do we ever use it on modern
disks? Maybe we can just remove this support.
Badblocks is definitely still used in some configurations.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Avi Kivity wrote:
It definitely should, especially on x86-64, where the page size isn't
guaranteed by the ABI (on i386, the ABI guarantees a 4K page size; on
x86-64 it can be up to 64K.)
Wouldn't that be ia64?
No, the x86-64 EFI ABI permits page sizes up to 64K. Currently, of
course,
From: Anton Blanchard <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 15:42:36 -0600
> > The easiest way to fix this would be to always park the swap magic at
> > the offset of the smallest page size in use, which is 4K. This is
> > analogous how the offset for the ext2/3 superblock got fixed at 1K
Hi,
> Our current swap layout has issues with variable page size kernels.
> Instead of using the page size at runtime, base it on the minimum page
> size the architecture supports.
A hacked up patch to userspace utilities to test the kernel patch. BTW
It looks like there are some real bugs
Hi Peter,
> The easiest way to fix this would be to always park the swap magic at
> the offset of the smallest page size in use, which is 4K. This is
> analogous how the offset for the ext2/3 superblock got fixed at 1K --
> for 1K blocks, it's the second block, but for larger blocks, it's
H. Peter Anvin wrote:
David Miller wrote:
Thanks, but that still leaves PAGE_SIZE available for some
architectures and not for others shouldn't this be moved inside
__KERNEL__ in i386 and x86_64 then?
I definitely think so.
It definitely should, especially on x86-64, where the page size
On 3/8/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
> By the way, it's a massive snafu that the swap area magic number is
> dependent on PAGE_SIZE. There is absolutely no good reason for that.
Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.
Okay this really
Anton Blanchard wrote:
By the way, it's a massive snafu that the swap area magic number is
dependent on PAGE_SIZE. There is absolutely no good reason for that.
Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.
The easiest way to fix this would be to always park
> By the way, it's a massive snafu that the swap area magic number is
> dependent on PAGE_SIZE. There is absolutely no good reason for that.
Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.
Anton
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Mar 08, 2007 at 09:05:48AM -0800, H. Peter Anvin wrote:
> Christoph Hellwig wrote:
> >No, no no. We should never export PAGE_SIZE. We might export NBPG
> >as deprecated symbol for gdb if it really needs it, but that should
> >happen only on a.out systems, and it it should be a true
Christoph Hellwig wrote:
No, no no. We should never export PAGE_SIZE. We might export NBPG
as deprecated symbol for gdb if it really needs it, but that should
happen only on a.out systems, and it it should be a true constant,
not depending on PAGE_SIZE.
I've Cc'ed the gdb list on whether they
On Thu, Mar 08, 2007 at 04:08:52PM +, Christoph Hellwig wrote:
> No, no no. We should never export PAGE_SIZE. We might export NBPG
> as deprecated symbol for gdb if it really needs it, but that should
> happen only on a.out systems, and it it should be a true constant,
> not depending on
On Thu, Mar 08, 2007 at 07:53:49AM -0800, Arjan van de Ven wrote:
> > > > PAGE_SIZE should not be available at all. Please use getpagesize()
> > > > instead.
> > >
> > > While I agree, NBPG is a bit of a problem, although it's only needed for
> > > aout
> > > coredumps AFAICT, but still needed
On Thu, 2007-03-08 at 09:00 +, Christoph Hellwig wrote:
> On Thu, Mar 08, 2007 at 03:18:04AM +0100, Roman Zippel wrote:
> > Hi,
> >
> > On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
> >
> > > PAGE_SIZE should not be available at all. Please use getpagesize()
> > > instead.
> >
>
On Thu, Mar 08, 2007 at 03:18:04AM +0100, Roman Zippel wrote:
> Hi,
>
> On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
>
> > PAGE_SIZE should not be available at all. Please use getpagesize()
> > instead.
>
> While I agree, NBPG is a bit of a problem, although it's only needed for
On Wed, Mar 07, 2007 at 09:28:15PM -0800, David Brown wrote:
> >While I agree, NBPG is a bit of a problem, although it's only needed for
> >aout
> >coredumps AFAICT, but still needed to compile e.g. gdb.
>
> Well then how does gdb deal with ia64? because PAGE_SIZE and friends
> aren't available
On Thu, 2007-03-08 at 09:00 +, Christoph Hellwig wrote:
On Thu, Mar 08, 2007 at 03:18:04AM +0100, Roman Zippel wrote:
Hi,
On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
PAGE_SIZE should not be available at all. Please use getpagesize()
instead.
While I agree,
On Thu, Mar 08, 2007 at 07:53:49AM -0800, Arjan van de Ven wrote:
PAGE_SIZE should not be available at all. Please use getpagesize()
instead.
While I agree, NBPG is a bit of a problem, although it's only needed for
aout
coredumps AFAICT, but still needed to compile e.g.
On Thu, Mar 08, 2007 at 04:08:52PM +, Christoph Hellwig wrote:
No, no no. We should never export PAGE_SIZE. We might export NBPG
as deprecated symbol for gdb if it really needs it, but that should
happen only on a.out systems, and it it should be a true constant,
not depending on
Christoph Hellwig wrote:
No, no no. We should never export PAGE_SIZE. We might export NBPG
as deprecated symbol for gdb if it really needs it, but that should
happen only on a.out systems, and it it should be a true constant,
not depending on PAGE_SIZE.
I've Cc'ed the gdb list on whether they
On Thu, Mar 08, 2007 at 09:05:48AM -0800, H. Peter Anvin wrote:
Christoph Hellwig wrote:
No, no no. We should never export PAGE_SIZE. We might export NBPG
as deprecated symbol for gdb if it really needs it, but that should
happen only on a.out systems, and it it should be a true constant,
By the way, it's a massive snafu that the swap area magic number is
dependent on PAGE_SIZE. There is absolutely no good reason for that.
Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.
Anton
-
To unsubscribe from this list: send the line unsubscribe
Anton Blanchard wrote:
By the way, it's a massive snafu that the swap area magic number is
dependent on PAGE_SIZE. There is absolutely no good reason for that.
Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.
The easiest way to fix this would be to always park
On 3/8/07, Anton Blanchard [EMAIL PROTECTED] wrote:
By the way, it's a massive snafu that the swap area magic number is
dependent on PAGE_SIZE. There is absolutely no good reason for that.
Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.
Okay this really seems
H. Peter Anvin wrote:
David Miller wrote:
Thanks, but that still leaves PAGE_SIZE available for some
architectures and not for others shouldn't this be moved inside
__KERNEL__ in i386 and x86_64 then?
I definitely think so.
It definitely should, especially on x86-64, where the page size
Hi Peter,
The easiest way to fix this would be to always park the swap magic at
the offset of the smallest page size in use, which is 4K. This is
analogous how the offset for the ext2/3 superblock got fixed at 1K --
for 1K blocks, it's the second block, but for larger blocks, it's part
Hi,
Our current swap layout has issues with variable page size kernels.
Instead of using the page size at runtime, base it on the minimum page
size the architecture supports.
A hacked up patch to userspace utilities to test the kernel patch. BTW
It looks like there are some real bugs here:
From: Anton Blanchard [EMAIL PROTECTED]
Date: Thu, 8 Mar 2007 15:42:36 -0600
The easiest way to fix this would be to always park the swap magic at
the offset of the smallest page size in use, which is 4K. This is
analogous how the offset for the ext2/3 superblock got fixed at 1K --
Avi Kivity wrote:
It definitely should, especially on x86-64, where the page size isn't
guaranteed by the ABI (on i386, the ABI guarantees a 4K page size; on
x86-64 it can be up to 64K.)
Wouldn't that be ia64?
No, the x86-64 EFI ABI permits page sizes up to 64K. Currently, of
course,
Anton Blanchard wrote:
2. The badblocks stuff is PAGE_SIZEd too. Do we ever use it on modern
disks? Maybe we can just remove this support.
Badblocks is definitely still used in some configurations.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hi,
I might be missing something but doesn't this break every
SWAP partition that was created with something other than
MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the page size :)
The other
Anton Blanchard wrote:
Hi,
I might be missing something but doesn't this break every
SWAP partition that was created with something other than
MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Thu, 08 Mar 2007 20:18:28 -0800
Anton Blanchard wrote:
The other option is to create a v3 swap format that doesnt use any
PAGE_SIZE parameters.
The best thing to do would be to look for the magic both at PAGE_SIZE
(for compatibility) and
David Miller wrote:
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Thu, 08 Mar 2007 20:18:28 -0800
Anton Blanchard wrote:
The other option is to create a v3 swap format that doesnt use any
PAGE_SIZE parameters.
The best thing to do would be to look for the magic both at PAGE_SIZE
(for
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Thu, 08 Mar 2007 20:31:05 -0800
The advantage would be that it wouldn't require a v3 for platforms for
which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
percentage of systems.
You still have to look for the darn magic in two
On Wed, Mar 07, 2007 at 09:28:15PM -0800, David Brown wrote:
While I agree, NBPG is a bit of a problem, although it's only needed for
aout
coredumps AFAICT, but still needed to compile e.g. gdb.
Well then how does gdb deal with ia64? because PAGE_SIZE and friends
aren't available for that
On Thu, Mar 08, 2007 at 03:18:04AM +0100, Roman Zippel wrote:
Hi,
On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
PAGE_SIZE should not be available at all. Please use getpagesize()
instead.
While I agree, NBPG is a bit of a problem, although it's only needed for aout
While I agree, NBPG is a bit of a problem, although it's only needed for aout
coredumps AFAICT, but still needed to compile e.g. gdb.
Well then how does gdb deal with ia64? because PAGE_SIZE and friends
aren't available for that arch same with ppc.
Looking at the gdb code they do have places
Hi,
On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
> PAGE_SIZE should not be available at all. Please use getpagesize()
> instead.
While I agree, NBPG is a bit of a problem, although it's only needed for aout
coredumps AFAICT, but still needed to compile e.g. gdb.
bye, Roman
-
To
Hi,
On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
PAGE_SIZE should not be available at all. Please use getpagesize()
instead.
While I agree, NBPG is a bit of a problem, although it's only needed for aout
coredumps AFAICT, but still needed to compile e.g. gdb.
bye, Roman
-
To
While I agree, NBPG is a bit of a problem, although it's only needed for aout
coredumps AFAICT, but still needed to compile e.g. gdb.
Well then how does gdb deal with ia64? because PAGE_SIZE and friends
aren't available for that arch same with ppc.
Looking at the gdb code they do have places
On Mon, Mar 05, 2007 at 03:55:06PM -0800, David Brown wrote:
> I was rtfc'ing the code one day and noticed somethings about the
> PAGE_SIZE define that is kinda inconsistent around its relative
> location to the __KERNEL__ define.
>
> On some architectures the PAGE_SIZE is outside the __KERNEL__
On Mon, Mar 05, 2007 at 03:55:06PM -0800, David Brown wrote:
I was rtfc'ing the code one day and noticed somethings about the
PAGE_SIZE define that is kinda inconsistent around its relative
location to the __KERNEL__ define.
On some architectures the PAGE_SIZE is outside the __KERNEL__
David Miller wrote:
Thanks, but that still leaves PAGE_SIZE available for some
architectures and not for others shouldn't this be moved inside
__KERNEL__ in i386 and x86_64 then?
I definitely think so.
It definitely should, especially on x86-64, where the page size isn't
guaranteed by the
From: "David Brown" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 16:04:24 -0800
> On 3/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "David Brown" <[EMAIL PROTECTED]>
> > Date: Mon, 5 Mar 2007 15:55:06 -0800
> >
> > > I'm kinda wondering how I'm supposed to write portable user-space code
>
On Mon, 5 Mar 2007 15:55:06 -0800 David Brown wrote:
> I was rtfc'ing the code one day and noticed somethings about the
> PAGE_SIZE define that is kinda inconsistent around its relative
> location to the __KERNEL__ define.
>
> On some architectures the PAGE_SIZE is outside the __KERNEL__ define
On 3/5/07, David Miller <[EMAIL PROTECTED]> wrote:
From: "David Brown" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 15:55:06 -0800
> I'm kinda wondering how I'm supposed to write portable user-space code
> if I want to use the PAGE_SIZE define on different architectures.
Call getpagesize().
From: "David Brown" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 15:55:06 -0800
> I'm kinda wondering how I'm supposed to write portable user-space code
> if I want to use the PAGE_SIZE define on different architectures.
Call getpagesize().
-
To unsubscribe from this list: send the line
David Brown a écrit :
I was rtfc'ing the code one day and noticed somethings about the
PAGE_SIZE define that is kinda inconsistent around its relative
location to the __KERNEL__ define.
On some architectures the PAGE_SIZE is outside the __KERNEL__ define
(i386 and x86_64) and on others its
I was rtfc'ing the code one day and noticed somethings about the
PAGE_SIZE define that is kinda inconsistent around its relative
location to the __KERNEL__ define.
On some architectures the PAGE_SIZE is outside the __KERNEL__ define
(i386 and x86_64) and on others its inside the define (ia64 and
I was rtfc'ing the code one day and noticed somethings about the
PAGE_SIZE define that is kinda inconsistent around its relative
location to the __KERNEL__ define.
On some architectures the PAGE_SIZE is outside the __KERNEL__ define
(i386 and x86_64) and on others its inside the define (ia64 and
David Brown a écrit :
I was rtfc'ing the code one day and noticed somethings about the
PAGE_SIZE define that is kinda inconsistent around its relative
location to the __KERNEL__ define.
On some architectures the PAGE_SIZE is outside the __KERNEL__ define
(i386 and x86_64) and on others its
From: David Brown [EMAIL PROTECTED]
Date: Mon, 5 Mar 2007 15:55:06 -0800
I'm kinda wondering how I'm supposed to write portable user-space code
if I want to use the PAGE_SIZE define on different architectures.
Call getpagesize().
-
To unsubscribe from this list: send the line unsubscribe
On 3/5/07, David Miller [EMAIL PROTECTED] wrote:
From: David Brown [EMAIL PROTECTED]
Date: Mon, 5 Mar 2007 15:55:06 -0800
I'm kinda wondering how I'm supposed to write portable user-space code
if I want to use the PAGE_SIZE define on different architectures.
Call getpagesize().
Thanks,
On Mon, 5 Mar 2007 15:55:06 -0800 David Brown wrote:
I was rtfc'ing the code one day and noticed somethings about the
PAGE_SIZE define that is kinda inconsistent around its relative
location to the __KERNEL__ define.
On some architectures the PAGE_SIZE is outside the __KERNEL__ define
From: David Brown [EMAIL PROTECTED]
Date: Mon, 5 Mar 2007 16:04:24 -0800
On 3/5/07, David Miller [EMAIL PROTECTED] wrote:
From: David Brown [EMAIL PROTECTED]
Date: Mon, 5 Mar 2007 15:55:06 -0800
I'm kinda wondering how I'm supposed to write portable user-space code
if I want to use
David Miller wrote:
Thanks, but that still leaves PAGE_SIZE available for some
architectures and not for others shouldn't this be moved inside
__KERNEL__ in i386 and x86_64 then?
I definitely think so.
It definitely should, especially on x86-64, where the page size isn't
guaranteed by the
68 matches
Mail list logo
