All of lore.kernel.org
 help / color / mirror / Atom feed
* Controlling memory allocation
@ 2009-09-12  2:23 sidc7
  2009-09-12  3:37 ` Bryan Donlan
  0 siblings, 1 reply; 4+ messages in thread
From: sidc7 @ 2009-09-12  2:23 UTC (permalink / raw)
  To: linux-kernel


I had a question regarding memory allocation. On a contemporary system, the
kernel will allocate physical frames on the DRAM based on availability. Is
it possible for the kernel to somehow restrict frame allocation for a
particular process to a particular address range. For e.g. Lets assume the
DRAM ranges from 00-FF, on a contemporary system, the entire range is
available for the kernel to allocate to the processes. Is it possible for
the kernel to say PID 1: the frames will be allocated only in 00-A0, PID2:
the frames will be allocated from A1 - D0 and PID3: will get frames from D1
- FF.

Thanks for your time and help in advance and I really hope someone can help
me with this question

Regards
-SC
-- 
View this message in context: http://www.nabble.com/Controlling-memory-allocation-tp25410990p25410990.html
Sent from the linux-kernel mailing list archive at Nabble.com.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Controlling memory allocation
  2009-09-12  2:23 Controlling memory allocation sidc7
@ 2009-09-12  3:37 ` Bryan Donlan
  2009-09-12  5:02   ` sidc7
       [not found]   ` <49f90a800909112201v7853be05mbd678dcb5fd20c5a@mail.gmail.com>
  0 siblings, 2 replies; 4+ messages in thread
From: Bryan Donlan @ 2009-09-12  3:37 UTC (permalink / raw)
  To: sidc7; +Cc: linux-kernel

On Fri, Sep 11, 2009 at 10:23 PM, sidc7 <siddhartha.chhabra@gmail.com> wrote:
>
> I had a question regarding memory allocation. On a contemporary system, the
> kernel will allocate physical frames on the DRAM based on availability. Is
> it possible for the kernel to somehow restrict frame allocation for a
> particular process to a particular address range. For e.g. Lets assume the
> DRAM ranges from 00-FF, on a contemporary system, the entire range is
> available for the kernel to allocate to the processes. Is it possible for
> the kernel to say PID 1: the frames will be allocated only in 00-A0, PID2:
> the frames will be allocated from A1 - D0 and PID3: will get frames from D1
> - FF.

The kernel has a concept of 'zones' that can be used to restrict
allocations as you say - however, user processes are the _least_
restricted. These zones are used to deal with old devices that can't
do DMAs above 16mb (so memory for their DMA buffers is allocated from
the 'DMA' zone), as well as to keep the kernel's internal
datastructures within the first 700mb or so of RAM (zone 'normal').
Memory used directly by userspace processes, including cache, can come
from any zone, including zone 'highmem'.

There's also some work on NUMA memory allocation policies - I'm not
too familiar with the details, but it does involve setting a
preference that pages for certain user processes get allocated from
certain memory banks near the CPU(s) that are executing the process.

Note that in both cases the assignments are somewhat static - zones
are set at compile time and are used solely as a workaround for
hardware limitations; exactly which are used depend on your
architecture (although the _types_ of zones available are fixed). See
include/linux/mmzones.h NUMA is determined by your hardware
configuration. And processes are never assigned just a contiguous,
exclusive range of pages to use, as there's no benefit in doing so -
what happens if something else took some of those first and it runs
out, after all?

For more information about zones, see
http://lxr.linux.no/linux+v2.6.31/include/linux/mmzone.h#L190 and the
x86 arch init code starting at
http://lxr.linux.no/linux+v2.6.31/arch/x86/mm/init_32.c#L737 etc.
For more info on NUMA, see the userspace API at
http://linux.die.net/man/3/numa and the paper at
http://www.kernel.org/pub/linux/kernel/people/christoph/pmig/numamemory.pdf

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Controlling memory allocation
  2009-09-12  3:37 ` Bryan Donlan
@ 2009-09-12  5:02   ` sidc7
       [not found]   ` <49f90a800909112201v7853be05mbd678dcb5fd20c5a@mail.gmail.com>
  1 sibling, 0 replies; 4+ messages in thread
From: sidc7 @ 2009-09-12  5:02 UTC (permalink / raw)
  To: linux-kernel


Thanks for your quick reply. I understand that user processes can go anywhere
in memory and are least restricted. So what I am trying to do is to simulate
a system which has two different memory technologies forming the main memory
subsystem. And I am looking to simulate this on a real system which
obviously has only DRAM available, so I was wondering if the kernel can
restrict a particular process to get only pages from a particular part of
the DRAM, and I understand they wont be contiguos and some other
applications might take up the other available frames in that region, so in
essence what I am trying to do is to say that for a particular process (or a
set of processes) only a certain part of the DRAM is available, and when the
kernel runs out of memory on this region that it is using for this process,
it does what is done when no free frame is found, swap out another frame to
make space for this request.

I hope I am making some sense, so in essence my question can be re-framed
as, can the kernel "virtualize" memory for a particular process so only a
particular region of the memory is available for that particular process and
all other activities like page allocation and replacement take place for
this process only within this region and rest of the system functions
normally with the entire memory available for use

Thanks once again for your reply and I really appreciate all the help

Regards,
SC

Bryan Donlan wrote:
> 
> On Fri, Sep 11, 2009 at 10:23 PM, sidc7 <siddhartha.chhabra@gmail.com>
> wrote:
>>
>> I had a question regarding memory allocation. On a contemporary system,
>> the
>> kernel will allocate physical frames on the DRAM based on availability.
>> Is
>> it possible for the kernel to somehow restrict frame allocation for a
>> particular process to a particular address range. For e.g. Lets assume
>> the
>> DRAM ranges from 00-FF, on a contemporary system, the entire range is
>> available for the kernel to allocate to the processes. Is it possible for
>> the kernel to say PID 1: the frames will be allocated only in 00-A0,
>> PID2:
>> the frames will be allocated from A1 - D0 and PID3: will get frames from
>> D1
>> - FF.
> 
> The kernel has a concept of 'zones' that can be used to restrict
> allocations as you say - however, user processes are the _least_
> restricted. These zones are used to deal with old devices that can't
> do DMAs above 16mb (so memory for their DMA buffers is allocated from
> the 'DMA' zone), as well as to keep the kernel's internal
> datastructures within the first 700mb or so of RAM (zone 'normal').
> Memory used directly by userspace processes, including cache, can come
> from any zone, including zone 'highmem'.
> 
> There's also some work on NUMA memory allocation policies - I'm not
> too familiar with the details, but it does involve setting a
> preference that pages for certain user processes get allocated from
> certain memory banks near the CPU(s) that are executing the process.
> 
> Note that in both cases the assignments are somewhat static - zones
> are set at compile time and are used solely as a workaround for
> hardware limitations; exactly which are used depend on your
> architecture (although the _types_ of zones available are fixed). See
> include/linux/mmzones.h NUMA is determined by your hardware
> configuration. And processes are never assigned just a contiguous,
> exclusive range of pages to use, as there's no benefit in doing so -
> what happens if something else took some of those first and it runs
> out, after all?
> 
> For more information about zones, see
> http://lxr.linux.no/linux+v2.6.31/include/linux/mmzone.h#L190 and the
> x86 arch init code starting at
> http://lxr.linux.no/linux+v2.6.31/arch/x86/mm/init_32.c#L737 etc.
> For more info on NUMA, see the userspace API at
> http://linux.die.net/man/3/numa and the paper at
> http://www.kernel.org/pub/linux/kernel/people/christoph/pmig/numamemory.pdf
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

-- 
View this message in context: http://www.nabble.com/Controlling-memory-allocation-tp25410990p25411648.html
Sent from the linux-kernel mailing list archive at Nabble.com.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Controlling memory allocation
       [not found]   ` <49f90a800909112201v7853be05mbd678dcb5fd20c5a@mail.gmail.com>
@ 2009-09-12 17:28     ` Bryan Donlan
  0 siblings, 0 replies; 4+ messages in thread
From: Bryan Donlan @ 2009-09-12 17:28 UTC (permalink / raw)
  To: Siddhartha Chhabra; +Cc: linux-kernel

On Sat, Sep 12, 2009 at 1:01 AM, Siddhartha Chhabra
<siddhartha.chhabra@gmail.com> wrote:

> I hope I am making some sense, so in essence my question can be re-framed
> as, can the kernel "virtualize" memory for a particular process so only a
> particular region of the memory is available for that particular process and
> all other activities like page allocation and replacement take place for
> this process only within this region and rest of the system functions
> normally with the entire memory available for use
>
> Thanks once again for your reply and I really appreciate all the help

I'm not an expert on the Linux memory manager, but I don't think what
you're asking has been implemented in the kernel - although it might
be useful for your particular research, it's not really useful in the
real world, so nobody's had a need to implement it. Of course, feel
free to do so yourself :)

PS -  I received two copies of the message with different message IDs.
When replying to this message, just use reply to all from gmail, don't
copy and paste it into nabble as well. The CC will make sure it gets
to lkml.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-09-12 17:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-12  2:23 Controlling memory allocation sidc7
2009-09-12  3:37 ` Bryan Donlan
2009-09-12  5:02   ` sidc7
     [not found]   ` <49f90a800909112201v7853be05mbd678dcb5fd20c5a@mail.gmail.com>
2009-09-12 17:28     ` Bryan Donlan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.