On 09/15/2014 06:21 PM, Oleg Nesterov wrote:
> Hi Jerome,
>
> Not sure I understand this patch correctly, will try to read it later.
> But a couple of nits/questions anyway,
>
> On 09/15, Jerome Marchand wrote:
>>
>> +The ShmXXX lines only appears for shmem mapping. They show the amount of memory
>> +from the mapping that is currently:
>> + - resident in RAM but not mapped into any process (ShmNotMapped)
>
> But how can we know that it is not mapped by another process?
Its mapcount is zero.
>
> And in fact "not mapped" looks confusing (at least to me).
"Not mapped" as "not present in a page table". It does belong to a
userspace mapping though. I wonder if there is a less ambiguous terminology.
> IIUC it is actually
> mapped even by this process, just it never tried to fault these (resident or
> swapped) pages in. Right?
No these pages are in the page cache. This can happen when the only
process which have accessed these exits or munmap() the mapping.
>
>> +void update_shmem_stats(struct mem_size_stats *mss, struct vm_area_struct *vma,
>> + pgoff_t pgoff, unsigned long size)
>
> static?
>
>> +{
>> + int count = 0;
>> +
>> + switch (shmem_locate(vma, pgoff, &count)) {
>> + case SHMEM_RESIDENT:
>> + if (!count)
>> + mss->shmem_notmapped += size;
>> + break;
>> + case SHMEM_SWAP:
>> + mss->shmem_swap += size;
>> + break;
>> + }
>> +}
>
> It seems that shmem_locate() and shmem_vma() are only defined if CONFIG_SHMEM,
> probably this series needs more ifdef's.
Now I wonder. Did I try to compile this with CONFIG_SHMEM unset?
>
> And I am not sure why we ignore SHMEM_SWAPCACHE...
Hugh didn't like it as it is a small and transient value.
Thanks,
Jerome
>
> Oleg.
>
Attachment:
signature.asc
Description: OpenPGP digital signature