Re: where to get ZONE_MOVABLE pathces?

Re: where to get ZONE_MOVABLE pathces?

[Jacky(GuangXiang Lee)]

----- Original Message ----- 
From: "Mel Gorman" <mel@skynet.ie>
To: "Jacky(GuangXiang Lee)" <gxli@arca.com.cn>
Sent: Tuesday, October 16, 2007 8:50 PM
Subject: Re: where to get ZONE_MOVABLE pathces?



Can I precisely make the RAM range of a specific DIMM to be a independent
zone?
e.x., I have a machine with 2G RAM(in place of 2 DIMM socket , each socket
is plugged with 1G RAM)
then I divided in kernel startup:
 ZONE_DMA: 0~16M
ZONE_DMA32: 16M~1G
ZONE_READONLY:1G~2G (supposing this is my new created zone)
hence the third zone corresponds to a DIMM hardware.
right?


> On (16/10/07 16:24), Jacky(GuangXiang  Lee) didst pronounce:
> > hi Mel,
> > I feel I need more knowledgement about node/zone than reading your that
> > book.
>
> Very well, but it is reaching the point where you should consider
> mailing linux-mm or kernelnewbies so that others will see the answers.
>
> > I have some stupid questions please:
> > 1)In a typical server machine, what are the maximum sizes of each nodes?
Is
> > there some materials about this exists?
>
> The size of the node is only limited by the size of the physical address
> space supported by a machine.
>
> > 2)Are all nodes in the same physical space? e.x., node 1: 0~2G, node 2:
> > 2G~4G,node 3 :4G~6G...?
>
> Not necessarily. Nodes can be at any part of the physical address space.
> They are not necessarily contiguous and nodes can actually overlap in
> some cases. For example, this can happen
>
> Node 0: 0-2GB
> Node 1: 3-6GB
> Node 0: 8-10GB
>
> > 3)In a specific node, does its zones be divided arbitrarily?
> >
>
> No, zones holes pages that have a particular addressing limitation and
> what they mean varies slightly between architectures. On i386, ZONE_DMA
> is 16MB because there are devices that can only use a 24 bit physical
> address. On x86_64, you have ZONE_DMA32 because there are 32 bit devices
> on 64 bit machines.
>
> > Can you give some detailed materials or explain more minutely?
>
> I'm not aware of recent detailed information on the subject. However, if
> you follow the code path starting from
> mm/page_alloc.c#free_area_init_nodes(), you'll see how the zones get
> initialised at boot-time. This is the arch-independent zone-sizing code
> that is used by a number of architectures. You'll see how the arch is
> responsible for passing in an array of PFNs denoting where zones end and
> how this information is used to size zones.
>
> -- 
> Mel Gorman
> Part-time Phd Student                          Linux Technology Center
> University of Limerick                         IBM Dublin Software Lab


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: where to get ZONE_MOVABLE pathces?

[Mel Gorman]

On Wed, 2007-10-17 at 15:06 +0800, Jacky(GuangXiang Lee) wrote:

> Can I precisely make the RAM range of a specific DIMM to be a independent
> zone?

Technically, yes as nothing stops you. Again, look at what
mm/page_alloc.c#free_area_init_nodes() does to setup each of the zones
as they currently exist.

Also, to reiterate, using a zone is easiest for a prototype but it's
unlikely to be the final solution. You probably want to use page
migration and a page-allocation callback from your driver to move pages
you detect are read-only to flash.

> e.x., I have a machine with 2G RAM(in place of 2 DIMM socket , each socket
> is plugged with 1G RAM)
> then I divided in kernel startup:
>  ZONE_DMA: 0~16M
> ZONE_DMA32: 16M~1G
> ZONE_READONLY:1G~2G (supposing this is my new created zone)
> hence the third zone corresponds to a DIMM hardware.
> right?
> 

You cannot assume that PFN ranges correspond to DIMMs in the normal
case. However, in your specific case where you have a piece of flash
that you want to use as a DIMM, you know exactly what the PFN ranges
are.

-- 
Mel Gorman

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[00/18] Virtual Compound Page Support V2

[Christoph Lameter]

Allocations of larger pages are not reliable in Linux. If larger
pages have to be allocated then one faces various choices of allowing
graceful fallback or using vmalloc with a performance penalty due
to the use of a page table. Virtual Compound pages are
a simple solution out of this dilemma. If an allocation specifies
GFP_VFALLBACK then the page allocator will first attempt to satisfy
the request with physically contiguous memory. If that is not possible
then the page allocator will create a virtually contiguous memory
area for the caller. That way large allocations may perhaps be
considered "reliable" indepedent of the memory fragmentation situation.

This means that memory with optimal performance is used when available.
We are currently gradually introducing methods to reduce memory
defragmentation. The better these methods become the less the
chances that fallback will occur.

Fallback is rare in particular on machines with contemporary memory
sizes of 1G or more. It seems to take special load situations that
pin a lot of memory and systems with low memory in order to get
system memory so fragmented that the fallback scheme must kick in.

There is therefore a compile time option to switch on fallback for
testing purposes. Virtually mapped mmemory may behave differently
and the CONFIG_FALLBACK_ALWAYS option will insure that the code is
tested to deal with virtual memory.

The patchset then addresses a series of issues in the current code
through the use of fallbacks:

- Fallback for x86_64 stack allocations. The default stack size
  is 8k which requires an order 1 allocation.

- Removes the manual fallback to vmalloc for sparsemem
  through the use of GFP_VFALLBACK.

- Uses a compound page for the wait table in the zone thereby
  avoiding having to go through a page table to get to the
  data structures used for waiting on events in pages.

- Allows fallback for the order 2 allocation in the crypto
  subsystem.

- Allows fallback for the caller table used by SLUB when determining
  the call sites for slab caches for sysfs output.

- Allows a configurable stack size on x86_64 (up to 32k).

More uses are possible by simply adding GFP_VFALLBACK to the page
flags or by converting vmalloc calls to regular page allocator calls.

It is likely that we have had to avoid the use of larger memory areas
because of the reliability issues. The patch may simplify future coding
of handling large memoryh areas because these issues are taken care of
by the page allocator. For HPC uses we constantly have to deal with
demands for larger and larger memory areas to speed up various loads.

Additional patches exist to enable SLUB and the Large Blocksize Patchset
to use these fallbacks.

The patchset is also available via git from the largeblock git tree via

git pull
  git://git.kernel.org/pub/scm/linux/kernel/git/christoph/largeblocksize.git
    vcompound

V1->V2
- Remove some cleanup patches and the SLUB patches from this set.
- Transparent vcompound support through page_address() and
  virt_to_head_page().
- Additional use cases.
- Factor the code better for an easier read
- Add configurable stack size.
- Follow up on various suggestions made for V1

RFC->V1
- Complete support for all compound functions for virtual compound pages
  (including the compound_nth_page() necessary for LBS mmap support)
- Fix various bugs
- Fix i386 build

-- 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [13/18] x86_64: Allow fallback for the stack

[Nick Piggin]

On Wednesday 10 October 2007 04:39, Christoph Lameter wrote:
> On Mon, 8 Oct 2007, Nick Piggin wrote:
> > The tight memory restrictions on stack usage do not come about because
> > of the difficulty in increasing the stack size :) It is because we want
> > to keep stack sizes small!
> >
> > Increasing the stack size 4K uses another 4MB of memory for every 1000
> > threads you have, right?
> >
> > It would take a lot of good reason to move away from the general
> > direction we've been taking over the past years that 4/8K stacks are a
> > good idea for regular 32 and 64 bit builds in general.
>
> We already use 32k stacks on IA64. So the memory argument fail there.

I'm talking about generic code.


> > > I have some concerns about the medium NUMA systems (a few dozen of
> > > nodes) also running out of stack since more data is placed on the stack
> > > through the policy layer and since we may end up with a couple of
> > > stacked filesystems. Most of the current NUMA systems on x86_64 are
> > > basically two nodes on one motherboard. The use of NUMA controls is
> > > likely limited there and the complexity of the filesystems is also not
> > > high.
> >
> > The solution has until now always been to fix the problems so they don't
> > use so much stack. Maybe a bigger stack is OK for you for 1024+ CPU
> > systems, but I don't think you'd be able to make that assumption for most
> > normal systems.
>
> Yes that is why I made the stack size configurable.

Fine. I just don't see why you need this fallback.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [13/18] x86_64: Allow fallback for the stack

[Christoph Lameter]

On Tue, 9 Oct 2007, Nick Piggin wrote:

> > We already use 32k stacks on IA64. So the memory argument fail there.
> 
> I'm talking about generic code.

The stack size is set in arch code not in generic code.

> > > The solution has until now always been to fix the problems so they don't
> > > use so much stack. Maybe a bigger stack is OK for you for 1024+ CPU
> > > systems, but I don't think you'd be able to make that assumption for most
> > > normal systems.
> >
> > Yes that is why I made the stack size configurable.
> 
> Fine. I just don't see why you need this fallback.

So you would be ok with submitting the configurable stacksize patches 
separately without the fallback? 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [13/18] x86_64: Allow fallback for the stack

[Nick Piggin]

On Wednesday 10 October 2007 11:26, Christoph Lameter wrote:
> On Tue, 9 Oct 2007, Nick Piggin wrote:
> > > We already use 32k stacks on IA64. So the memory argument fail there.
> >
> > I'm talking about generic code.
>
> The stack size is set in arch code not in generic code.

Generic code must assume a 4K stack on 32-bit, in general (modulo
huge cpumasks and such, I guess).


> > > > The solution has until now always been to fix the problems so they
> > > > don't use so much stack. Maybe a bigger stack is OK for you for 1024+
> > > > CPU systems, but I don't think you'd be able to make that assumption
> > > > for most normal systems.
> > >
> > > Yes that is why I made the stack size configurable.
> >
> > Fine. I just don't see why you need this fallback.
>
> So you would be ok with submitting the configurable stacksize patches
> separately without the fallback?

Sure. It's already configurable on other architectures.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

where to get ZONE_MOVABLE pathces?

[Jacky(GuangXiang Lee)]

hi list ,

I am looking for Mel's patch about ZONE_MOVABLE
http://kerneltrap.org/mailarchive/linux-kernel/2007/1/25/48006


Who can tell me where to download those patches?
Thanks a lot.
Jacky




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: where to get ZONE_MOVABLE pathces?

[Mel Gorman]

On (10/10/07 11:36), Jacky(GuangXiang  Lee) didst pronounce:
> hi list ,
> 
> I am looking for Mel's patch about ZONE_MOVABLE
> http://kerneltrap.org/mailarchive/linux-kernel/2007/1/25/48006
> 
> Who can tell me where to download those patches?

They are already in mainline. Check out the latest kernel and look at
Documentation/kernel-parameters.txt for the kernelcore= and movablecore=
parameters.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>