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 fo
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&D in the
income statement of a publ
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
>> alloc
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
> allocatio
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
> readin
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. T
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 o
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 t
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 o
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 introdu
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 th
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 memory
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 th
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, 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. Y
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 b
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 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 m
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 is 12 so you can't set
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 is the
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 [EMA
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_SI
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
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 CONFIG_PAGE_SH
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 init=/tmp/bench-st
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:
>
>
> http://www.kernel.org/pub/linux/kernel/people/andrea
33 matches
Mail list logo
