Hi Christoph,

Did you have any thoughts on my follow-on question below?

Cheers,

Michael



On 10/14/2016 12:09 PM, Michael Kerrisk (man-pages) wrote:
> Hi Christoph,
> 
> On 13 October 2016 at 20:16, Christoph Lameter <[email protected]> wrote:
>> On Thu, 13 Oct 2016, Michael Kerrisk (man-pages) wrote:
>>
>>> @@ -100,7 +100,10 @@ If, however, the shared memory region was created with 
>>> the
>>>  .B SHM_HUGETLB
>>>  flag,
>>>  the huge pages will be allocated according to the policy specified
>>> -only if the page allocation is caused by the process that calls
>>> +only if the page allocation is caused by the thread that calls
>>> +.\"
>>> +.\" ??? Is it correct to change "process" to "thread" in the preceding 
>>> line?
>>
>> No leave it as process. Pages get one map refcount per page table
>> that references them (meaning a process). More than one map refcount means
>> that multiple processes have mapped the page.
>>
>>> @@ -300,7 +303,10 @@ is specified in
>>>  .IR flags ,
>>>  then the kernel will attempt to move all the existing pages
>>>  in the memory range so that they follow the policy.
>>> -Pages that are shared with other processes will not be moved.
>>> +Pages that are shared with other threads will not be moved.
>>> +.\"
>>> +.\" ??? Is it correct to change "processes" to "threads" in the preceding 
>>> line?
>>> +.\"
>>
>> Leave it. Same as before.
>>
>>>  If
>>>  then the kernel will attempt to move all existing pages in the memory range
>>> -regardless of whether other processes use the pages.
>>> -The calling process must be privileged
>>> +regardless of whether other threads use the pages.
>>> +.\"
>>> +.\" ??? Is it correct to change "processes" to "threads" in the preceding 
>>> line?
>>> +.\"
>>
>> Leave as process.
> 
> Thanks. So, are all the other cases where I changed "process" to
> "thread" okay then?
> 
> Cheers,
> 
> Michael
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Reply via email to