On Wed, Jul 25, 2007 at 04:39:04PM +0200, Andrea Arcangeli wrote:
> For the kernel stack btw, when alloc_pages(order=1) fails vmalloc
> should be used and 4k stacks can be dropped. Nobody does dma from the
> stack anymore these days IIRC (it doesn't work in all archs anyway).
I have recent code
On Tue, Jul 24, 2007 at 08:20:11PM -0700, William Lee Irwin III wrote:
> In any event, I've never been involved in a research project, though
I didn't mean it was supposed to be research project in some
University. But IIRC it was founded by what is defined as R in the
income statement of a
On Tue, Jul 24, 2007 at 08:20:11PM -0700, William Lee Irwin III wrote:
In any event, I've never been involved in a research project, though
I didn't mean it was supposed to be research project in some
University. But IIRC it was founded by what is defined as RD in the
income statement of a
On Wed, Jul 25, 2007 at 04:39:04PM +0200, Andrea Arcangeli wrote:
For the kernel stack btw, when alloc_pages(order=1) fails vmalloc
should be used and 4k stacks can be dropped. Nobody does dma from the
stack anymore these days IIRC (it doesn't work in all archs anyway).
I have recent code for
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
>> Actually I'd worked on what was called MPSS (Multiple Page Size Support)
>> before I ever started on pgcl. Some large portion of the pgcl proposal
>> as I presented it internally was to reduce the order of large page
>>
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
> Actually I'd worked on what was called MPSS (Multiple Page Size Support)
> before I ever started on pgcl. Some large portion of the pgcl proposal
> as I presented it internally was to reduce the order of large page
>
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
Actually I'd worked on what was called MPSS (Multiple Page Size Support)
before I ever started on pgcl. Some large portion of the pgcl proposal
as I presented it internally was to reduce the order of large page
allocations
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
Actually I'd worked on what was called MPSS (Multiple Page Size Support)
before I ever started on pgcl. Some large portion of the pgcl proposal
as I presented it internally was to reduce the order of large page
allocations
On 07/19/2007 01:50 AM, Andrea Arcangeli wrote:
On Wed, Jul 18, 2007 at 06:34:20PM +0200, Rene Herman wrote:
It says that highmem is not an issue due to no such thing as highmem even
existing on the machines with support for larger hard pagesizes, but this
wouldn't hold for soft pages. Sort
On Wed, Jul 18, 2007 at 06:34:20PM +0200, Rene Herman wrote:
> It says that highmem is not an issue due to no such thing as highmem even
> existing on the machines with support for larger hard pagesizes, but this
> wouldn't hold for soft pages. Sort of went "damn" in an x86 context upon
>
On 07/18/2007 03:32 PM, William Lee Irwin III wrote:
On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
kmalloced 4k naturally aligned object into userland). I wouldn't call
it tail packing, it's more a fine-granular pagecache with the already
available kmalloc granularities.
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
>> You may rest assured that it's technically feasible. It's been done.
>> The larger obstacles to all this are nontechnical.
On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
> Back then there was no variable
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
You may rest assured that it's technically feasible. It's been done.
The larger obstacles to all this are nontechnical.
On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
Back then there was no variable order
On 07/18/2007 03:32 PM, William Lee Irwin III wrote:
On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
kmalloced 4k naturally aligned object into userland). I wouldn't call
it tail packing, it's more a fine-granular pagecache with the already
available kmalloc granularities.
On Wed, Jul 18, 2007 at 06:34:20PM +0200, Rene Herman wrote:
It says that highmem is not an issue due to no such thing as highmem even
existing on the machines with support for larger hard pagesizes, but this
wouldn't hold for soft pages. Sort of went damn in an x86 context upon
reading
On 07/19/2007 01:50 AM, Andrea Arcangeli wrote:
On Wed, Jul 18, 2007 at 06:34:20PM +0200, Rene Herman wrote:
It says that highmem is not an issue due to no such thing as highmem even
existing on the machines with support for larger hard pagesizes, but this
wouldn't hold for soft pages. Sort
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
> You may rest assured that it's technically feasible. It's been done.
> The larger obstacles to all this are nontechnical.
Back then there was no variable order page size proposal, no slub,
generally nothing of that kind.
I
On Sat, Jul 07, 2007 at 01:52:28AM +0200, Andrea Arcangeli wrote:
> BTW, in a parallel thread (the thread where I've been suggested to
> post this), Rik rightfully mentioned Bill once also tried to get this
> working and basically asked for the differences. I don't know exactly
> what Bill did, I
On Sat, Jul 07, 2007 at 01:52:28AM +0200, Andrea Arcangeli wrote:
BTW, in a parallel thread (the thread where I've been suggested to
post this), Rik rightfully mentioned Bill once also tried to get this
working and basically asked for the differences. I don't know exactly
what Bill did, I only
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
You may rest assured that it's technically feasible. It's been done.
The larger obstacles to all this are nontechnical.
Back then there was no variable order page size proposal, no slub,
generally nothing of that kind.
I
On Fri, Jul 13, 2007 at 04:31:09PM +0200, Andrea Arcangeli wrote:
> On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
> > Sure. Fundamentally, though, I think it is the wrong approach to
> > take - it's a workaround for a big negative side effect of
> > increasing page size. It
On Fri, Jul 13, 2007 at 04:31:09PM +0200, Andrea Arcangeli wrote:
On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
Sure. Fundamentally, though, I think it is the wrong approach to
take - it's a workaround for a big negative side effect of
increasing page size. It introduces
On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
> Sure. Fundamentally, though, I think it is the wrong approach to
> take - it's a workaround for a big negative side effect of
> increasing page size. It introduces lots of complexity and
> difficult-to-test corner cases; judging by
On Fri, 2007-07-13 at 17:13 +1000, David Chinner wrote:
> On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
> > On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
> > > On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> > > > That's crap. Just because a machine has
On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
> On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
> > On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> > > That's crap. Just because a machine has lots of memory does not
> > > make it OK to waste lots of
On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
That's crap. Just because a machine has lots of memory does not
make it OK to waste lots of memory.
On Fri, 2007-07-13 at 17:13 +1000, David Chinner wrote:
On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
That's crap. Just because a machine has lots of
On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
Sure. Fundamentally, though, I think it is the wrong approach to
take - it's a workaround for a big negative side effect of
increasing page size. It introduces lots of complexity and
difficult-to-test corner cases; judging by the
On Thu, Jul 12, 2007 at 12:53:09PM -0500, Matt Mackall wrote:
> On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
> > The original idea of having a software page size larger than a
> > hardware page size, originated at SUSE by myself and Andi Kleen while
> > helping AMD to design
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
> The original idea of having a software page size larger than a
> hardware page size, originated at SUSE by myself and Andi Kleen while
> helping AMD to design their amd64 cpu,
Original? This was done on VAXen and in Mach ages
On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
> On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> > That's crap. Just because a machine has lots of memory does not
> > make it OK to waste lots of memory.
>
> It's not just wasted, it lowers overhead all over the place.
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> That's crap. Just because a machine has lots of memory does not
> make it OK to waste lots of memory.
It's not just wasted, it lowers overhead all over the place. Yes, the
benefit of wasting less pagecache may largely outweight the
On Thu, Jul 12, 2007 at 01:14:36PM +0200, Andrea Arcangeli wrote:
> On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
> > I need really large filesystems that contain both small and large files to
> > work more efficiently on small boxes where we can't throw endless amounts of
> > RAM
On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
> I need really large filesystems that contain both small and large files to
> work more efficiently on small boxes where we can't throw endless amounts of
> RAM and CPUs at the problem. Hence things like 64k page size are just not an
On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
I need really large filesystems that contain both small and large files to
work more efficiently on small boxes where we can't throw endless amounts of
RAM and CPUs at the problem. Hence things like 64k page size are just not an
On Thu, Jul 12, 2007 at 01:14:36PM +0200, Andrea Arcangeli wrote:
On Thu, Jul 12, 2007 at 10:12:56AM +1000, David Chinner wrote:
I need really large filesystems that contain both small and large files to
work more efficiently on small boxes where we can't throw endless amounts of
RAM and
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
That's crap. Just because a machine has lots of memory does not
make it OK to waste lots of memory.
It's not just wasted, it lowers overhead all over the place. Yes, the
benefit of wasting less pagecache may largely outweight the
On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
That's crap. Just because a machine has lots of memory does not
make it OK to waste lots of memory.
It's not just wasted, it lowers overhead all over the place. Yes,
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
The original idea of having a software page size larger than a
hardware page size, originated at SUSE by myself and Andi Kleen while
helping AMD to design their amd64 cpu,
Original? This was done on VAXen and in Mach ages ago.
On Thu, Jul 12, 2007 at 12:53:09PM -0500, Matt Mackall wrote:
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
The original idea of having a software page size larger than a
hardware page size, originated at SUSE by myself and Andi Kleen while
helping AMD to design their
On Tue, Jul 10, 2007 at 12:11:48PM +0200, Andrea Arcangeli wrote:
> On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
> > I think you've misunderstood why large block sizes are important to
> > XFS. The major benefits to XFS of larger block size have almost
> > nothing to do with
On Tue, Jul 10, 2007 at 12:11:48PM +0200, Andrea Arcangeli wrote:
On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
I think you've misunderstood why large block sizes are important to
XFS. The major benefits to XFS of larger block size have almost
nothing to do with data
On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
> I think you've misunderstood why large block sizes are important to
> XFS. The major benefits to XFS of larger block size have almost
> nothing to do with data layout or in memory indexing - it comes from
> metadata btree's getting
On Mon, Jul 09, 2007 at 09:20:31AM +1000, David Chinner wrote:
I think you've misunderstood why large block sizes are important to
XFS. The major benefits to XFS of larger block size have almost
nothing to do with data layout or in memory indexing - it comes from
metadata btree's getting much
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
> The xfs developers for example want to enlarge their filesystem
> blocksize (the filesystem blocksize has a tradeoff similar to the
> PAGE_SIZE, the larger the faster the filesystem but more disk space is
> potentially wasted),
I
On Sat, Jul 07, 2007 at 08:53:49PM +0200, Jan Engelhardt wrote:
>
> On Jul 7 2007 00:26, Andrea Arcangeli wrote:
> >Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
>
> I wonder what happens if the soft page size gets set to 2048 bytes :)
Well the min allowed shift
On Sat, Jul 07, 2007 at 08:53:49PM +0200, Jan Engelhardt wrote:
On Jul 7 2007 00:26, Andrea Arcangeli wrote:
Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
I wonder what happens if the soft page size gets set to 2048 bytes :)
Well the min allowed shift is 12 so you can't set
On Sat, Jul 07, 2007 at 12:26:51AM +0200, Andrea Arcangeli wrote:
The xfs developers for example want to enlarge their filesystem
blocksize (the filesystem blocksize has a tradeoff similar to the
PAGE_SIZE, the larger the faster the filesystem but more disk space is
potentially wasted),
I
Jan Engelhardt wrote:
On Jul 7 2007 00:26, Andrea Arcangeli wrote:
Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
I wonder what happens if the soft page size gets set to 2048 bytes :)
That won't work, because the smallest granularity the x86
MMU supports is 4kB.
--
Politics
On Jul 7 2007 00:26, Andrea Arcangeli wrote:
>Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
I wonder what happens if the soft page size gets set to 2048 bytes :)
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Sat, Jul 07, 2007 at 05:01:57PM +1000, Paul Mackerras wrote:
> Andrea Arcangeli writes:
>
> > So my whole idea is to once and for all to decuple the size of the
> > pte-entry (4k on x86/amd64) with the page allocator granularity. The
> > HARD_PAGE_SHIFT will be 4k still, the common code
On Fri, Jul 06, 2007 at 06:47:01PM -0700, Badari Pulavarty wrote:
> Hmm.. I didn't have any luck booting my machine with the patchset
> (with 8k pagesize) :(
>
> It fails to find the partition table on my hard drive.
I'm afraid I can't reproduce :( Best would be to track that code and
see
Andrea Arcangeli writes:
> So my whole idea is to once and for all to decuple the size of the
> pte-entry (4k on x86/amd64) with the page allocator granularity. The
> HARD_PAGE_SHIFT will be 4k still, the common code PAGE_SIZE will be
> variable and configurable at compile time with
Andrea Arcangeli writes:
So my whole idea is to once and for all to decuple the size of the
pte-entry (4k on x86/amd64) with the page allocator granularity. The
HARD_PAGE_SHIFT will be 4k still, the common code PAGE_SIZE will be
variable and configurable at compile time with
On Fri, Jul 06, 2007 at 06:47:01PM -0700, Badari Pulavarty wrote:
Hmm.. I didn't have any luck booting my machine with the patchset
(with 8k pagesize) :(
It fails to find the partition table on my hard drive.
I'm afraid I can't reproduce :( Best would be to track that code and
see what's
On Sat, Jul 07, 2007 at 05:01:57PM +1000, Paul Mackerras wrote:
Andrea Arcangeli writes:
So my whole idea is to once and for all to decuple the size of the
pte-entry (4k on x86/amd64) with the page allocator granularity. The
HARD_PAGE_SHIFT will be 4k still, the common code PAGE_SIZE will
On Jul 7 2007 00:26, Andrea Arcangeli wrote:
Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
I wonder what happens if the soft page size gets set to 2048 bytes :)
Jan
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Jan Engelhardt wrote:
On Jul 7 2007 00:26, Andrea Arcangeli wrote:
Subject: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
I wonder what happens if the soft page size gets set to 2048 bytes :)
That won't work, because the smallest granularity the x86
MMU supports is 4kB.
--
Politics
On Sat, 2007-07-07 at 00:26 +0200, Andrea Arcangeli wrote:
..
> The following simple bench seems to run fine on one real hardware and
> on kvm (a friend of mine failed so far to run it on his hardware
> though, so perhaps some driver triggers some remaining bugs) when
> booted as
On Sat, 2007-07-07 at 00:26 +0200, Andrea Arcangeli wrote:
> Hello,
>
..
>
> If you want to help/look here the patch:
>
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.22-rc7/hard-page-size
>
Very interesting patch set. I really would like to support for it.
I
On Fri, Jul 06, 2007 at 04:33:21PM -0700, Dave Hansen wrote:
> The patch looks really interesting, it's just a little hard to parse
> with all of the s/4096/PAGE_SIZE/ bits around. Those cleanups, along
> with the s/PAGE_SIZE/HARD_PAGE_SIZE/ parts would be great in a
> separated-out patch so that
On Sat, 2007-07-07 at 00:26 +0200, Andrea Arcangeli wrote:
> for the hack week at opensuse (see http://idea.opensuse.org/) I've
> been working on a new feature called CONFIG_PAGE_SHIFT.
...
> If you want to help/look here the patch:
>
>
>
Hello,
for the hack week at opensuse (see http://idea.opensuse.org/) I've
been working on a new feature called CONFIG_PAGE_SHIFT.
In the last few days while reading the topics of the VM summit I
answered I disliked the dependency on defrag for reliable I/O and I
suggested I had an alternative
Hello,
for the hack week at opensuse (see http://idea.opensuse.org/) I've
been working on a new feature called CONFIG_PAGE_SHIFT.
In the last few days while reading the topics of the VM summit I
answered I disliked the dependency on defrag for reliable I/O and I
suggested I had an alternative
On Sat, 2007-07-07 at 00:26 +0200, Andrea Arcangeli wrote:
for the hack week at opensuse (see http://idea.opensuse.org/) I've
been working on a new feature called CONFIG_PAGE_SHIFT.
...
If you want to help/look here the patch:
On Fri, Jul 06, 2007 at 04:33:21PM -0700, Dave Hansen wrote:
The patch looks really interesting, it's just a little hard to parse
with all of the s/4096/PAGE_SIZE/ bits around. Those cleanups, along
with the s/PAGE_SIZE/HARD_PAGE_SIZE/ parts would be great in a
separated-out patch so that the
On Sat, 2007-07-07 at 00:26 +0200, Andrea Arcangeli wrote:
Hello,
..
If you want to help/look here the patch:
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.22-rc7/hard-page-size
Very interesting patch set. I really would like to support for it.
I would
On Sat, 2007-07-07 at 00:26 +0200, Andrea Arcangeli wrote:
..
The following simple bench seems to run fine on one real hardware and
on kvm (a friend of mine failed so far to run it on his hardware
though, so perhaps some driver triggers some remaining bugs) when
booted as
68 matches
Mail list logo
