On Tue, 30 Jan 2007, Peter Zijlstra wrote:
> I'm guessing this will involve page migration.
Not necessarily. The approach also works without page migration. Depends
on an intelligent allocation scheme that stays off the areas of interest
to those restricted to low area allocations as much as po
On Mon, 29 Jan 2007, Andrew Morton wrote:
> On Mon, 29 Jan 2007 15:37:29 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > With a alloc_pages_range() one would be able to specify upper and lower
> > boundaries.
>
> Is there a proposal anywhere regarding how this would be implemen
On Mon, 2007-01-29 at 16:09 -0800, Andrew Morton wrote:
> On Mon, 29 Jan 2007 15:37:29 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > With a alloc_pages_range() one would be able to specify upper and lower
> > boundaries.
>
> Is there a proposal anywhere regarding how this woul
On Mon, 29 Jan 2007 15:37:29 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> With a alloc_pages_range() one would be able to specify upper and lower
> boundaries.
Is there a proposal anywhere regarding how this would be implemented?
-
To unsubscribe from this list: send the line "unsu
On Mon, 29 Jan 2007, Russell King wrote:
> This sounds like it could help ARM where we have some weird DMA areas.
Some ARM platforms have no need for a ZONE_DMA. The code in mm allows you
to not compile ZONE_DMA support into these kernels.
> What will help even more is if the block layer can al
On Mon, Jan 29, 2007 at 02:45:06PM -0800, Christoph Lameter wrote:
> On Mon, 29 Jan 2007, Andrew Morton wrote:
>
> > > All 64 bit machine will only have a single zone if we have such a range
> > > alloc mechanism. The 32bit ones with HIGHMEM wont be able to avoid it,
> > > true. But all arches t
On Mon, 29 Jan 2007, Andrew Morton wrote:
> > All 64 bit machine will only have a single zone if we have such a range
> > alloc mechanism. The 32bit ones with HIGHMEM wont be able to avoid it,
> > true. But all arches that do not need gymnastics to access their memory
> > will be able run with
On Mon, 29 Jan 2007 13:54:38 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Jan 2007, Andrew Morton wrote:
>
> > > The main benefit is a significant simplification of the VM, leading to
> > > robust and reliable operations and a reduction of the maintenance
> > > headache
On Fri, 26 Jan 2007, Andrew Morton wrote:
> > The main benefit is a significant simplification of the VM, leading to
> > robust and reliable operations and a reduction of the maintenance
> > headaches coming with the additional zones.
> >
> > If we would introduce the ability of allocating from
On Fri, 26 Jan 2007 11:58:18 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > If the only demonstrable benefit is a saving of a few k of text on a small
> > number of machines then things are looking very grim, IMO.
>
> The main benefit is a significant simplification of the VM, leadi
On Fri, 26 Jan 2007, Andrew Morton wrote:
> As Mel points out, distros will ship with CONFIG_ZONE_DMA=y, so the number
> of machines which will actually benefit from this change is really small.
> And the benefit to those few machines will also, I suspect, be small.
>
> > > - We kicked around so
On Fri, 26 Jan 2007 07:56:09 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Jan 2007, Andrew Morton wrote:
>
> > - They add zillions of ifdefs
>
> They just add a few for ZONE_DMA where we alreaday have similar ifdefs for
> ZONE_DMA32 and ZONE_HIGHMEM.
I refreshed my mem
On Fri, 26 Jan 2007, Christoph Lameter wrote:
On Fri, 26 Jan 2007, Mel Gorman wrote:
For arches that do not have HIGHMEM other zones would be okay too it
seems.
It would, but it'd obscure the code to take advantage of that.
No MOVABLE memory for 64 bit platforms that do not have HIGHMEM rig
On Fri, 26 Jan 2007, Mel Gorman wrote:
> > For arches that do not have HIGHMEM other zones would be okay too it
> > seems.
> It would, but it'd obscure the code to take advantage of that.
No MOVABLE memory for 64 bit platforms that do not have HIGHMEM right now?
> The anti-fragmentation code cou
On Fri, 26 Jan 2007, Christoph Lameter wrote:
On Thu, 25 Jan 2007, Mel Gorman wrote:
The following 8 patches against 2.6.20-rc4-mm1 create a zone called
ZONE_MOVABLE that is only usable by allocations that specify both __GFP_HIGHMEM
and __GFP_MOVABLE. This has the effect of keeping all non-mov
On Thu, 25 Jan 2007, Mel Gorman wrote:
> The following 8 patches against 2.6.20-rc4-mm1 create a zone called
> ZONE_MOVABLE that is only usable by allocations that specify both
> __GFP_HIGHMEM
> and __GFP_MOVABLE. This has the effect of keeping all non-movable pages
> within a single memory parti
On Fri, 26 Jan 2007, Mel Gorman wrote:
> I haven't thought about it much so I probably am missing something. The major
> difference I see is when only one zone is present. In that case, a number of
> loops presumably get optimised away and the behavior is very different
> (presumably better althou
On Fri, 26 Jan 2007, Andrew Morton wrote:
> - They add zillions of ifdefs
They just add a few for ZONE_DMA where we alreaday have similar ifdefs for
ZONE_DMA32 and ZONE_HIGHMEM.
> - They make the VM's behaviour diverge between different platforms and
> between differen configs on the same pla
On Fri, 26 Jan 2007, Andrew Morton wrote:
On Thu, 25 Jan 2007 23:44:58 + (GMT)
Mel Gorman <[EMAIL PROTECTED]> wrote:
The following 8 patches against 2.6.20-rc4-mm1 create a zone called
ZONE_MOVABLE
Argh. These surely get all tangled up with the
make-zones-optional-by-adding-zillions-of-
On Thu, 25 Jan 2007 23:44:58 + (GMT)
Mel Gorman <[EMAIL PROTECTED]> wrote:
> The following 8 patches against 2.6.20-rc4-mm1 create a zone called
> ZONE_MOVABLE
Argh. These surely get all tangled up with the
make-zones-optional-by-adding-zillions-of-ifdef patches:
deal-with-cases-of-zone_dma
The following 8 patches against 2.6.20-rc4-mm1 create a zone called
ZONE_MOVABLE that is only usable by allocations that specify both __GFP_HIGHMEM
and __GFP_MOVABLE. This has the effect of keeping all non-movable pages
within a single memory partition while allowing movable allocations to be
satis
21 matches
Mail list logo
