Is swap really needed when RAM's aplenty
On 08/20/2010 11:22 AM, Michael Hennebry wrote:
> On Fri, 20 Aug 2010, JD wrote:
>
>> On 08/20/2010 06:44 AM, Michael Hennebry wrote:
>>> On Thu, 19 Aug 2010, JD wrote:
>>>
>>>> On 08/19/2010 02:15 PM, Michael Hennebry wrote:
>>>>> On Thu, 19 Aug 2010, JD wrote:
>>>>>
>>>>>> Problem comes as Michael explains, that when a process needs a large
>>>>>> "physically contiguous" chunk of memory, it might not be available.
>>>>>> That said, usually, requests for physically contiguous memory is only
>>>>>> needed when wanting to map very large number of DMA pages for
>>>>>> doing direct physical I/O.
>>>>>> Otherwise, a process itself does not need to have physically contiguous
>>>>>> pages. Only the virtual space allocated to that "malloc" or large buffer
>>>>>> declaration in a program, is contiguous.
>>>>> Why would malloc or a large buffer declaration
>>>>> require physically contiguous memory?
>>>> It is done in a driver on the process' behalf when doing direct physical
>>>> IO .
>>>> typically, such blocks of physically contiguous chunks memory are set
>>>> aside during boot.
>>>> I have also seen special embedded linux drivers that provide an ioctl
>>>> to let the process get a set of physically contiguous pages and map the
>>>> space
>>>> to user virtual space. This is for performance reasons to reduce copying
>>>> from user space to kernel space when large amounts of data need to be
>>>> moved.
>>>> This is not a new idea. it has been around for many years. I first
>>>> saw it in Linux back in 1998/1999.
>>> Perhaps I misunderstood.
>>> Do both of the following necessarily require physically contiguous memory?
>>> char fred[69000];
>>> char *greg=malloc(96000);
>>> Would they sometimes require physically contiguous memory?
>>>
>> It depends on what you want to achieve.
>> If the target device you will write that buffer to can handle a
>> contiguous physical space of, say ... a few pages, then you
>> would want to ask the special driver of that device, via an ioctl,
>> to give you those pages, and map them to user virtual space -
>> i.e. you would not allocate them from the heap.
> It makes sense that if a process insists on physically
> contiguous memory and can't get it, the process would die,
Not necessarily. It is not clear what you mean by insist.
For example, the process could be put to sleep until the
contiguous mem became available. But this is not achived via
malloc or the likes.
> but the above code does not tell the compiler what is to be achieved.
And it cannot. It is not the compiler's job.
> In the following, would fred or greg necessarily
> refer to physically contiguous memory?
No! Not at all.
In older versions of unix, there used to be a facility
for the user to ask for phsycially contiguous mem.
That has disappeared from most versions of unix
and clones.
There are drivers that, upon bootup, acquire
from the kernel's internal interface, for X many contiguous
pages. The driver then manages this pool of pages.
The driver would export to the user process (header file) an ioctl
through which the user process could request a number
of pages, and they would then be mapped to user virtual
space so the user could write to those pages, and when
the write(2) call was made to write those pages, there
would be NO copy from user space to kernel space.
This was done in some embedded linux drivers for some
certain devices to achieve higher performance.
So, let's not beat this thing any further.
You might want to do your own googling.
> #include<stdlib.h>
> extern void hank(char *);
>
> int main(*args[], int argsNum)
> {
> char fred[69000];
> char *greg=malloc(96000);
> char *greg=malloc(96000);
> hank(fred);
> hank(greg);
> return 0;
> }
>
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
|
