* [rfc 0/2] Introducing VmFlags field into smaps output
@ 2012-10-22 19:14 Cyrill Gorcunov
2012-10-22 19:14 ` [rfc 1/2] [RFC] procfs: Add VmFlags field in " Cyrill Gorcunov
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Cyrill Gorcunov @ 2012-10-22 19:14 UTC (permalink / raw)
To: linux-kernel; +Cc: Pavel Emelyanov, Andrew Morton, Peter Zijlstra
Hi guys, during c/r sessions we've found that there is no way at
the moment to fetch some VMA associated flags, such as mlock()
and madvise(), thus the patches in this series intorduce new field
into "smaps" output called VmFlags where all flags associated with
the particular VMA is shown in two letter mnemonic.
Strictly speaking for c/r we only need mlock/madvise bits but it
has been said that providing just a few flags looks somehow inconsistent.
So all flags are here now.
Please review. Comments and complains are quite welcome!
Thanks,
Cyrill
^ permalink raw reply [flat|nested] 19+ messages in thread* [rfc 1/2] [RFC] procfs: Add VmFlags field in smaps output 2012-10-22 19:14 [rfc 0/2] Introducing VmFlags field into smaps output Cyrill Gorcunov @ 2012-10-22 19:14 ` Cyrill Gorcunov 2012-10-22 19:14 ` [rfc 2/2] [RFC] procfs: Documantation -- Add VmFlags field description Cyrill Gorcunov 2012-10-22 19:29 ` [rfc 0/2] Introducing VmFlags field into smaps output Andrew Morton 2 siblings, 0 replies; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-22 19:14 UTC (permalink / raw) To: linux-kernel Cc: Pavel Emelyanov, Andrew Morton, Peter Zijlstra, Cyrill Gorcunov [-- Attachment #1: mm-vma-flags-4 --] [-- Type: text/plain, Size: 2490 bytes --] When we do restore VMA area after checkpoint we would like to know if the area was locked or say it had mergeable attribute, but at moment the kernel does not provide such information, thus we can't figure out if we should call mlock/madvise on VMA restore. This patch adds new VmFlags field to smaps output with vma->vm_flags encoded. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> CC: Pavel Emelyanov <xemul@parallels.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> --- fs/proc/task_mmu.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) Index: linux-2.6.git/fs/proc/task_mmu.c =================================================================== --- linux-2.6.git.orig/fs/proc/task_mmu.c +++ linux-2.6.git/fs/proc/task_mmu.c @@ -480,6 +480,36 @@ static int smaps_pte_range(pmd_t *pmd, u return 0; } +static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) +{ + /* + * Don't forget to update Documentation/ on changes. + */ +#define __VM_FLAG(_f) (!!(vma->vm_flags & (_f))) + seq_printf(m, "VmFlags: " + "RD:%d WR:%d EX:%d SH:%d MR:%d " + "MW:%d ME:%d MS:%d GD:%d PF:%d " + "DW:%d LO:%d IO:%d SR:%d RR:%d " + "DC:%d DE:%d AC:%d NR:%d HT:%d " + "NL:%d AR:%d DD:%d MM:%d HG:%d " + "NH:%d MG:%d\n", + __VM_FLAG(VM_READ), __VM_FLAG(VM_WRITE), + __VM_FLAG(VM_EXEC), __VM_FLAG(VM_SHARED), + __VM_FLAG(VM_MAYREAD), __VM_FLAG(VM_MAYWRITE), + __VM_FLAG(VM_MAYEXEC), __VM_FLAG(VM_MAYSHARE), + __VM_FLAG(VM_GROWSDOWN), __VM_FLAG(VM_PFNMAP), + __VM_FLAG(VM_DENYWRITE), __VM_FLAG(VM_LOCKED), + __VM_FLAG(VM_IO), __VM_FLAG(VM_SEQ_READ), + __VM_FLAG(VM_RAND_READ), __VM_FLAG(VM_DONTCOPY), + __VM_FLAG(VM_DONTEXPAND), __VM_FLAG(VM_ACCOUNT), + __VM_FLAG(VM_NORESERVE), __VM_FLAG(VM_HUGETLB), + __VM_FLAG(VM_NONLINEAR), __VM_FLAG(VM_ARCH_1), + __VM_FLAG(VM_DONTDUMP), __VM_FLAG(VM_MIXEDMAP), + __VM_FLAG(VM_HUGEPAGE), __VM_FLAG(VM_NOHUGEPAGE), + __VM_FLAG(VM_MERGEABLE)); +#undef __VM_FLAG +} + static int show_smap(struct seq_file *m, void *v, int is_pid) { struct proc_maps_private *priv = m->private; @@ -535,6 +565,8 @@ static int show_smap(struct seq_file *m, seq_printf(m, "Nonlinear: %8lu kB\n", mss.nonlinear >> 10); + show_smap_vma_flags(m, vma); + if (m->count < m->size) /* vma is copied successfully */ m->version = (vma != get_gate_vma(task->mm)) ? vma->vm_start : 0; ^ permalink raw reply [flat|nested] 19+ messages in thread
* [rfc 2/2] [RFC] procfs: Documantation -- Add VmFlags field description 2012-10-22 19:14 [rfc 0/2] Introducing VmFlags field into smaps output Cyrill Gorcunov 2012-10-22 19:14 ` [rfc 1/2] [RFC] procfs: Add VmFlags field in " Cyrill Gorcunov @ 2012-10-22 19:14 ` Cyrill Gorcunov 2012-10-22 19:29 ` [rfc 0/2] Introducing VmFlags field into smaps output Andrew Morton 2 siblings, 0 replies; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-22 19:14 UTC (permalink / raw) To: linux-kernel Cc: Pavel Emelyanov, Andrew Morton, Peter Zijlstra, Cyrill Gorcunov [-- Attachment #1: mm-vma-flags-doc --] [-- Type: text/plain, Size: 2934 bytes --] Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> CC: Pavel Emelyanov <xemul@parallels.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> --- Documentation/filesystems/proc.txt | 38 ++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) Index: linux-2.6.git/Documentation/filesystems/proc.txt =================================================================== --- linux-2.6.git.orig/Documentation/filesystems/proc.txt +++ linux-2.6.git/Documentation/filesystems/proc.txt @@ -142,7 +142,7 @@ Table 1-1: Process specific entries in / pagemap Page table stack Report full stack trace, enable via CONFIG_STACKTRACE smaps a extension based on maps, showing the memory consumption of - each mapping + each mapping and flags associated with it .............................................................................. For example, to get the status information of a process, all you have to do is @@ -415,6 +415,7 @@ Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 374 kB +VmFlags: RD:1 WR:0 EX:1 SH:0 MR:1 MW:1 ME:1 MS:0 GD:0 PF:0 DW:1 LO:0 IO:0 SR:0 RR:0 DC:0 DE:0 AC:0 NR:0 HT:0 NL:0 AR:0 DD:0 MM:0 HG:0 NH:0 MG:0 The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping @@ -430,6 +431,41 @@ and a page is modified, the file page is "Swap" shows how much would-be-anonymous memory is also used, but out on swap. +"VmFlags" field deserves a separate description. This member represents the kernel +flags associated with the particular virtual memory area in two letter encoded +manner. The codes are the following: + RD - readable + WR - writeable + EX - executable + SH - shared + MR - may read + MW - may write + ME - may execute + MS - may share + GD - stack segment growns down + PF - pure PFN range + DW - disabled write to the mapped file + LO - pages are locked in memory + IO - memory mapped I/O area + SR - sequential read advise provided + RR - random read advise provided + DC - do not copy area on fork + DE - do not expand area on remapping + AC - area is accountable + NR - swap space is not reserved for the area + HT - area uses huge tlb pages + NL - non-linear mapping + AR - architecture specific flag + DD - do not include area into core dump + MM - mixed map area + HG - huge page advise flag + NH - no-huge page advise flag + MG - mergable advise flag + +Note that there is no guarantee that every flag and associated mnemonic will +be present in all further kernel releases. Things get changed, the flags may +be vanished or the reverse -- new added. + This file is only present if the CONFIG_MMU kernel configuration option is enabled. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 19:14 [rfc 0/2] Introducing VmFlags field into smaps output Cyrill Gorcunov 2012-10-22 19:14 ` [rfc 1/2] [RFC] procfs: Add VmFlags field in " Cyrill Gorcunov 2012-10-22 19:14 ` [rfc 2/2] [RFC] procfs: Documantation -- Add VmFlags field description Cyrill Gorcunov @ 2012-10-22 19:29 ` Andrew Morton 2012-10-22 19:39 ` Cyrill Gorcunov 2012-10-22 20:50 ` Pavel Emelyanov 2 siblings, 2 replies; 19+ messages in thread From: Andrew Morton @ 2012-10-22 19:29 UTC (permalink / raw) To: Cyrill Gorcunov; +Cc: linux-kernel, Pavel Emelyanov, Peter Zijlstra On Mon, 22 Oct 2012 23:14:52 +0400 Cyrill Gorcunov <gorcunov@openvz.org> wrote: > Hi guys, during c/r sessions we've found that there is no way at > the moment to fetch some VMA associated flags, such as mlock() > and madvise(), thus the patches in this series intorduce new field > into "smaps" output called VmFlags where all flags associated with > the particular VMA is shown in two letter mnemonic. > > Strictly speaking for c/r we only need mlock/madvise bits but it > has been said that providing just a few flags looks somehow inconsistent. > So all flags are here now. > > Please review. Comments and complains are quite welcome! Sigh, it's still a pretty nasty-looking interface. Better ideas are welcomed. I joined the patches into one, massaged the changelog a bit and added a couple more paragraphs explaining why we're doing this to ourselves. From: Cyrill Gorcunov <gorcunov@openvz.org> Subject: procfs: add VmFlags field in smaps output During c/r sessions we've found that there is no way at the moment to fetch some VMA associated flags, such as mlock() and madvise(), thus the patches in this series intorduce new field into "smaps" output called VmFlags where all flags associated with the particular VMA is shown in two letter mnemonic. Strictly speaking for c/r we only need mlock/madvise bits but it has been said that providing just a few flags looks somehow inconsistent. So all flags are here now. When we restore a VMA after checkpoint we would like to know if the area was locked or say it had mergeable attribute, but at moment the kernel does not provide such information, thus we can't figure out if we should call mlock/madvise on VMA restore. This patch adds new VmFlags field to smaps output with vma->vm_flags encoded. This feature is made available on CONFIG_CHECKPOINT_RESTORE=n kernels, as other applications may start to use these fields. The data is encoded in a somewhat awkward name:value form, to encourage userspace to be prepared for fields being added or removed in the future. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- Documentation/filesystems/proc.txt | 38 ++++++++++++++++++++++++++- fs/proc/task_mmu.c | 32 ++++++++++++++++++++++ 2 files changed, 69 insertions(+), 1 deletion(-) diff -puN fs/proc/task_mmu.c~procfs-add-vmflags-field-in-smaps-output fs/proc/task_mmu.c --- a/fs/proc/task_mmu.c~procfs-add-vmflags-field-in-smaps-output +++ a/fs/proc/task_mmu.c @@ -526,6 +526,36 @@ static int smaps_pte_range(pmd_t *pmd, u return 0; } +static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) +{ + /* + * Don't forget to update Documentation/ on changes. + */ +#define __VM_FLAG(_f) (!!(vma->vm_flags & (_f))) + seq_printf(m, "VmFlags: " + "RD:%d WR:%d EX:%d SH:%d MR:%d " + "MW:%d ME:%d MS:%d GD:%d PF:%d " + "DW:%d LO:%d IO:%d SR:%d RR:%d " + "DC:%d DE:%d AC:%d NR:%d HT:%d " + "NL:%d AR:%d DD:%d MM:%d HG:%d " + "NH:%d MG:%d\n", + __VM_FLAG(VM_READ), __VM_FLAG(VM_WRITE), + __VM_FLAG(VM_EXEC), __VM_FLAG(VM_SHARED), + __VM_FLAG(VM_MAYREAD), __VM_FLAG(VM_MAYWRITE), + __VM_FLAG(VM_MAYEXEC), __VM_FLAG(VM_MAYSHARE), + __VM_FLAG(VM_GROWSDOWN), __VM_FLAG(VM_PFNMAP), + __VM_FLAG(VM_DENYWRITE), __VM_FLAG(VM_LOCKED), + __VM_FLAG(VM_IO), __VM_FLAG(VM_SEQ_READ), + __VM_FLAG(VM_RAND_READ), __VM_FLAG(VM_DONTCOPY), + __VM_FLAG(VM_DONTEXPAND), __VM_FLAG(VM_ACCOUNT), + __VM_FLAG(VM_NORESERVE), __VM_FLAG(VM_HUGETLB), + __VM_FLAG(VM_NONLINEAR), __VM_FLAG(VM_ARCH_1), + __VM_FLAG(VM_DONTDUMP), __VM_FLAG(VM_MIXEDMAP), + __VM_FLAG(VM_HUGEPAGE), __VM_FLAG(VM_NOHUGEPAGE), + __VM_FLAG(VM_MERGEABLE)); +#undef __VM_FLAG +} + static int show_smap(struct seq_file *m, void *v, int is_pid) { struct proc_maps_private *priv = m->private; @@ -581,6 +611,8 @@ static int show_smap(struct seq_file *m, seq_printf(m, "Nonlinear: %8lu kB\n", mss.nonlinear >> 10); + show_smap_vma_flags(m, vma); + if (m->count < m->size) /* vma is copied successfully */ m->version = (vma != get_gate_vma(task->mm)) ? vma->vm_start : 0; diff -puN Documentation/filesystems/proc.txt~procfs-add-vmflags-field-in-smaps-output Documentation/filesystems/proc.txt --- a/Documentation/filesystems/proc.txt~procfs-add-vmflags-field-in-smaps-output +++ a/Documentation/filesystems/proc.txt @@ -142,7 +142,7 @@ Table 1-1: Process specific entries in / pagemap Page table stack Report full stack trace, enable via CONFIG_STACKTRACE smaps a extension based on maps, showing the memory consumption of - each mapping + each mapping and flags associated with it .............................................................................. For example, to get the status information of a process, all you have to do is @@ -415,6 +415,7 @@ Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 374 kB +VmFlags: RD:1 WR:0 EX:1 SH:0 MR:1 MW:1 ME:1 MS:0 GD:0 PF:0 DW:1 LO:0 IO:0 SR:0 RR:0 DC:0 DE:0 AC:0 NR:0 HT:0 NL:0 AR:0 DD:0 MM:0 HG:0 NH:0 MG:0 The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping @@ -430,6 +431,41 @@ and a page is modified, the file page is "Swap" shows how much would-be-anonymous memory is also used, but out on swap. +"VmFlags" field deserves a separate description. This member represents the kernel +flags associated with the particular virtual memory area in two letter encoded +manner. The codes are the following: + RD - readable + WR - writeable + EX - executable + SH - shared + MR - may read + MW - may write + ME - may execute + MS - may share + GD - stack segment growns down + PF - pure PFN range + DW - disabled write to the mapped file + LO - pages are locked in memory + IO - memory mapped I/O area + SR - sequential read advise provided + RR - random read advise provided + DC - do not copy area on fork + DE - do not expand area on remapping + AC - area is accountable + NR - swap space is not reserved for the area + HT - area uses huge tlb pages + NL - non-linear mapping + AR - architecture specific flag + DD - do not include area into core dump + MM - mixed map area + HG - huge page advise flag + NH - no-huge page advise flag + MG - mergable advise flag + +Note that there is no guarantee that every flag and associated mnemonic will +be present in all further kernel releases. Things get changed, the flags may +be vanished or the reverse -- new added. + This file is only present if the CONFIG_MMU kernel configuration option is enabled. _ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 19:29 ` [rfc 0/2] Introducing VmFlags field into smaps output Andrew Morton @ 2012-10-22 19:39 ` Cyrill Gorcunov 2012-10-22 20:50 ` Pavel Emelyanov 1 sibling, 0 replies; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-22 19:39 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Pavel Emelyanov, Peter Zijlstra On Mon, Oct 22, 2012 at 12:29:34PM -0700, Andrew Morton wrote: > On Mon, 22 Oct 2012 23:14:52 +0400 > Cyrill Gorcunov <gorcunov@openvz.org> wrote: > > > Hi guys, during c/r sessions we've found that there is no way at > > the moment to fetch some VMA associated flags, such as mlock() > > and madvise(), thus the patches in this series intorduce new field > > into "smaps" output called VmFlags where all flags associated with > > the particular VMA is shown in two letter mnemonic. > > > > Strictly speaking for c/r we only need mlock/madvise bits but it > > has been said that providing just a few flags looks somehow inconsistent. > > So all flags are here now. > > > > Please review. Comments and complains are quite welcome! > > Sigh, it's still a pretty nasty-looking interface. Better ideas are > welcomed. Well, one usable thing could be (I guess) to print only flags set. Since usually not that many flags are set on vma. This would shrink output at least. > I joined the patches into one, massaged the changelog a bit and added a > couple more paragraphs explaining why we're doing this to ourselves. Thanks! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 19:29 ` [rfc 0/2] Introducing VmFlags field into smaps output Andrew Morton 2012-10-22 19:39 ` Cyrill Gorcunov @ 2012-10-22 20:50 ` Pavel Emelyanov 2012-10-22 20:56 ` Cyrill Gorcunov 1 sibling, 1 reply; 19+ messages in thread From: Pavel Emelyanov @ 2012-10-22 20:50 UTC (permalink / raw) To: Andrew Morton; +Cc: Cyrill Gorcunov, linux-kernel, Peter Zijlstra On 10/22/2012 11:29 PM, Andrew Morton wrote: > On Mon, 22 Oct 2012 23:14:52 +0400 > Cyrill Gorcunov <gorcunov@openvz.org> wrote: > >> Hi guys, during c/r sessions we've found that there is no way at >> the moment to fetch some VMA associated flags, such as mlock() >> and madvise(), thus the patches in this series intorduce new field >> into "smaps" output called VmFlags where all flags associated with >> the particular VMA is shown in two letter mnemonic. >> >> Strictly speaking for c/r we only need mlock/madvise bits but it >> has been said that providing just a few flags looks somehow inconsistent. >> So all flags are here now. >> >> Please review. Comments and complains are quite welcome! > > Sigh, it's still a pretty nasty-looking interface. Better ideas are > welcomed. Maybe just a string of two-letter short names like VmFlags: rd wr sh sr ? I.e. in a way flags line looks in cpuinfo file. > I joined the patches into one, massaged the changelog a bit and added a > couple more paragraphs explaining why we're doing this to ourselves. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 20:50 ` Pavel Emelyanov @ 2012-10-22 20:56 ` Cyrill Gorcunov 2012-10-22 21:34 ` Cyrill Gorcunov 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-22 20:56 UTC (permalink / raw) To: Pavel Emelyanov; +Cc: Andrew Morton, linux-kernel, Peter Zijlstra On Tue, Oct 23, 2012 at 12:50:48AM +0400, Pavel Emelyanov wrote: > On 10/22/2012 11:29 PM, Andrew Morton wrote: > > On Mon, 22 Oct 2012 23:14:52 +0400 > > Cyrill Gorcunov <gorcunov@openvz.org> wrote: > > > >> Hi guys, during c/r sessions we've found that there is no way at > >> the moment to fetch some VMA associated flags, such as mlock() > >> and madvise(), thus the patches in this series intorduce new field > >> into "smaps" output called VmFlags where all flags associated with > >> the particular VMA is shown in two letter mnemonic. > >> > >> Strictly speaking for c/r we only need mlock/madvise bits but it > >> has been said that providing just a few flags looks somehow inconsistent. > >> So all flags are here now. > >> > >> Please review. Comments and complains are quite welcome! > > > > Sigh, it's still a pretty nasty-looking interface. Better ideas are > > welcomed. > > Maybe just a string of two-letter short names like > > VmFlags: rd wr sh sr > > ? > > I.e. in a way flags line looks in cpuinfo file. Yup, I think this will be shorter and more agreeable. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 20:56 ` Cyrill Gorcunov @ 2012-10-22 21:34 ` Cyrill Gorcunov 2012-10-22 21:51 ` Andrew Morton 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-22 21:34 UTC (permalink / raw) To: Pavel Emelyanov, Andrew Morton; +Cc: LKML, Peter Zijlstra On Tue, Oct 23, 2012 at 12:56:41AM +0400, Cyrill Gorcunov wrote: > On Tue, Oct 23, 2012 at 12:50:48AM +0400, Pavel Emelyanov wrote: > > On 10/22/2012 11:29 PM, Andrew Morton wrote: > > > On Mon, 22 Oct 2012 23:14:52 +0400 > > > Cyrill Gorcunov <gorcunov@openvz.org> wrote: > > > > > >> Hi guys, during c/r sessions we've found that there is no way at > > >> the moment to fetch some VMA associated flags, such as mlock() > > >> and madvise(), thus the patches in this series intorduce new field > > >> into "smaps" output called VmFlags where all flags associated with > > >> the particular VMA is shown in two letter mnemonic. > > >> > > >> Strictly speaking for c/r we only need mlock/madvise bits but it > > >> has been said that providing just a few flags looks somehow inconsistent. > > >> So all flags are here now. > > >> > > >> Please review. Comments and complains are quite welcome! > > > > > > Sigh, it's still a pretty nasty-looking interface. Better ideas are > > > welcomed. > > > > Maybe just a string of two-letter short names like > > > > VmFlags: rd wr sh sr > > > > ? > > > > I.e. in a way flags line looks in cpuinfo file. > > Yup, I think this will be shorter and more agreeable. What about something like below instead? --- From: Cyrill Gorcunov <gorcunov@openvz.org> Subject: procfs: add VmFlags field in smaps output v2 During c/r sessions we've found that there is no way at the moment to fetch some VMA associated flags, such as mlock() and madvise(). This leads us to a problem -- we don't know if we should call for mlock() and/or madvise() after restore on the vma area we're bringing back to life. This patch intorduces a new field into "smaps" output called VmFlags, where all set flags associated with the particular VMA is shown as two letter mnemonics. [ Strictly speaking for c/r we only need mlock/madvise bits but it has been said that providing just a few flags looks somehow inconsistent. So all flags are here now. ] This feature is made available on CONFIG_CHECKPOINT_RESTORE=n kernels, as other applications may start to use these fields. The data is encoded in a somewhat awkward two letters mnemonic form, to encourage userspace to be prepared for fields being added or removed in the future. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- Documentation/filesystems/proc.txt | 40 ++++++++++++++++++++++++++++-- fs/proc/task_mmu.c | 49 +++++++++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+), 2 deletions(-) Index: linux-2.6.git/Documentation/filesystems/proc.txt =================================================================== --- linux-2.6.git.orig/Documentation/filesystems/proc.txt +++ linux-2.6.git/Documentation/filesystems/proc.txt @@ -142,7 +142,7 @@ Table 1-1: Process specific entries in / pagemap Page table stack Report full stack trace, enable via CONFIG_STACKTRACE smaps a extension based on maps, showing the memory consumption of - each mapping + each mapping and flags associated with it .............................................................................. For example, to get the status information of a process, all you have to do is @@ -415,8 +415,9 @@ Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 374 kB +VmFlags: rd ex mr mw me de -The first of these lines shows the same information as is displayed for the +the first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping (size), the amount of the mapping that is currently resident in RAM (RSS), the process' proportional share of this mapping (PSS), the number of clean and @@ -430,6 +431,41 @@ and a page is modified, the file page is "Swap" shows how much would-be-anonymous memory is also used, but out on swap. +"VmFlags" field deserves a separate description. This member represents the kernel +flags associated with the particular virtual memory area in two letter encoded +manner. The codes are the following: + rd - readable + wr - writeable + ex - executable + sh - shared + mr - may read + mw - may write + me - may execute + ms - may share + gd - stack segment growns down + pf - pure PFN range + dw - disabled write to the mapped file + lo - pages are locked in memory + io - memory mapped I/O area + sr - sequential read advise provided + rr - random read advise provided + dc - do not copy area on fork + de - do not expand area on remapping + ac - area is accountable + nr - swap space is not reserved for the area + ht - area uses huge tlb pages + nl - non-linear mapping + ar - architecture specific flag + dd - do not include area into core dump + mm - mixed map area + hg - huge page advise flag + nh - no-huge page advise flag + mg - mergable advise flag + +Note that there is no guarantee that every flag and associated mnemonic will +be present in all further kernel releases. Things get changed, the flags may +be vanished or the reverse -- new added. + This file is only present if the CONFIG_MMU kernel configuration option is enabled. Index: linux-2.6.git/fs/proc/task_mmu.c =================================================================== --- linux-2.6.git.orig/fs/proc/task_mmu.c +++ linux-2.6.git/fs/proc/task_mmu.c @@ -480,6 +480,53 @@ static int smaps_pte_range(pmd_t *pmd, u return 0; } +static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) +{ + /* + * Don't forget to update Documentation/ on changes. + */ + +#define __seq_show_vmflag(_f, _s) \ + do { \ + if (vma->vm_flags & (_f)) \ + seq_puts(m, _s); \ + } while (0) + + seq_puts(m, "VmFlags: "); + + __seq_show_vmflag(VM_READ, "rd "); + __seq_show_vmflag(VM_WRITE, "wr "); + __seq_show_vmflag(VM_EXEC, "ex "); + __seq_show_vmflag(VM_SHARED, "sh "); + __seq_show_vmflag(VM_MAYREAD, "mr "); + __seq_show_vmflag(VM_MAYWRITE, "mw "); + __seq_show_vmflag(VM_MAYEXEC, "me "); + __seq_show_vmflag(VM_MAYSHARE, "ms "); + __seq_show_vmflag(VM_GROWSDOWN, "gd "); + __seq_show_vmflag(VM_PFNMAP, "pf "); + __seq_show_vmflag(VM_DENYWRITE, "dw "); + __seq_show_vmflag(VM_LOCKED, "lo "); + __seq_show_vmflag(VM_IO, "io "); + __seq_show_vmflag(VM_SEQ_READ, "sr "); + __seq_show_vmflag(VM_RAND_READ, "rr "); + __seq_show_vmflag(VM_DONTCOPY, "dc "); + __seq_show_vmflag(VM_DONTEXPAND,"de "); + __seq_show_vmflag(VM_ACCOUNT, "ac "); + __seq_show_vmflag(VM_NORESERVE, "nr "); + __seq_show_vmflag(VM_HUGETLB, "ht "); + __seq_show_vmflag(VM_NONLINEAR, "nl "); + __seq_show_vmflag(VM_ARCH_1, "ar "); + __seq_show_vmflag(VM_DONTDUMP, "dd "); + __seq_show_vmflag(VM_MIXEDMAP, "mm "); + __seq_show_vmflag(VM_HUGEPAGE, "hg "); + __seq_show_vmflag(VM_NOHUGEPAGE,"nh "); + __seq_show_vmflag(VM_MERGEABLE, "mg "); + + seq_putc(m, '\n'); + +#undef __seq_show_vmflag +} + static int show_smap(struct seq_file *m, void *v, int is_pid) { struct proc_maps_private *priv = m->private; @@ -535,6 +582,8 @@ static int show_smap(struct seq_file *m, seq_printf(m, "Nonlinear: %8lu kB\n", mss.nonlinear >> 10); + show_smap_vma_flags(m, vma); + if (m->count < m->size) /* vma is copied successfully */ m->version = (vma != get_gate_vma(task->mm)) ? vma->vm_start : 0; ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 21:34 ` Cyrill Gorcunov @ 2012-10-22 21:51 ` Andrew Morton 2012-10-23 6:13 ` Cyrill Gorcunov 0 siblings, 1 reply; 19+ messages in thread From: Andrew Morton @ 2012-10-22 21:51 UTC (permalink / raw) To: Cyrill Gorcunov; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Tue, 23 Oct 2012 01:34:49 +0400 Cyrill Gorcunov <gorcunov@openvz.org> wrote: > > ... > > +VmFlags: rd ex mr mw me de ho hum OK, let's do that. > +static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) > +{ > + /* > + * Don't forget to update Documentation/ on changes. > + */ > + > +#define __seq_show_vmflag(_f, _s) \ > + do { \ > + if (vma->vm_flags & (_f)) \ > + seq_puts(m, _s); \ > + } while (0) > + > + seq_puts(m, "VmFlags: "); > + > + __seq_show_vmflag(VM_READ, "rd "); > + __seq_show_vmflag(VM_WRITE, "wr "); > + __seq_show_vmflag(VM_EXEC, "ex "); > + __seq_show_vmflag(VM_SHARED, "sh "); > + __seq_show_vmflag(VM_MAYREAD, "mr "); > + __seq_show_vmflag(VM_MAYWRITE, "mw "); > + __seq_show_vmflag(VM_MAYEXEC, "me "); > + __seq_show_vmflag(VM_MAYSHARE, "ms "); > + __seq_show_vmflag(VM_GROWSDOWN, "gd "); > + __seq_show_vmflag(VM_PFNMAP, "pf "); > + __seq_show_vmflag(VM_DENYWRITE, "dw "); > + __seq_show_vmflag(VM_LOCKED, "lo "); > + __seq_show_vmflag(VM_IO, "io "); > + __seq_show_vmflag(VM_SEQ_READ, "sr "); > + __seq_show_vmflag(VM_RAND_READ, "rr "); > + __seq_show_vmflag(VM_DONTCOPY, "dc "); > + __seq_show_vmflag(VM_DONTEXPAND,"de "); > + __seq_show_vmflag(VM_ACCOUNT, "ac "); > + __seq_show_vmflag(VM_NORESERVE, "nr "); > + __seq_show_vmflag(VM_HUGETLB, "ht "); > + __seq_show_vmflag(VM_NONLINEAR, "nl "); > + __seq_show_vmflag(VM_ARCH_1, "ar "); > + __seq_show_vmflag(VM_DONTDUMP, "dd "); > + __seq_show_vmflag(VM_MIXEDMAP, "mm "); > + __seq_show_vmflag(VM_HUGEPAGE, "hg "); > + __seq_show_vmflag(VM_NOHUGEPAGE,"nh "); > + __seq_show_vmflag(VM_MERGEABLE, "mg "); > + > + seq_putc(m, '\n'); > + > +#undef __seq_show_vmflag > +} This code would be much denser if we did the old static const char foo[] = "rdwrexshmrmw..."; unsigned i; for (i = 0; i < BITS_PER_LONG; i++) { if (flags & (1 << i)) seq_printf("%c%c ", foo[i * 2], foo[i * 2 + 1]); } trick. But then we'd have to remember to fix foo[] each time we alter the flags, so maybe let's not do that. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-22 21:51 ` Andrew Morton @ 2012-10-23 6:13 ` Cyrill Gorcunov 2012-10-23 6:30 ` Andrew Morton 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-23 6:13 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Mon, Oct 22, 2012 at 02:51:58PM -0700, Andrew Morton wrote: ... > > + __seq_show_vmflag(VM_DONTEXPAND,"de "); > > + __seq_show_vmflag(VM_ACCOUNT, "ac "); > > + __seq_show_vmflag(VM_NORESERVE, "nr "); > > + __seq_show_vmflag(VM_HUGETLB, "ht "); > > + __seq_show_vmflag(VM_NONLINEAR, "nl "); > > + __seq_show_vmflag(VM_ARCH_1, "ar "); > > + __seq_show_vmflag(VM_DONTDUMP, "dd "); > > + __seq_show_vmflag(VM_MIXEDMAP, "mm "); > > + __seq_show_vmflag(VM_HUGEPAGE, "hg "); > > + __seq_show_vmflag(VM_NOHUGEPAGE,"nh "); ... > > This code would be much denser if we did the old > > static const char foo[] = "rdwrexshmrmw..."; > unsigned i; > > for (i = 0; i < BITS_PER_LONG; i++) { > if (flags & (1 << i)) > seq_printf("%c%c ", foo[i * 2], foo[i * 2 + 1]); > } > > trick. But then we'd have to remember to fix foo[] each time we > alter the flags, so maybe let's not do that. Yup, but not only that, this kind of trick hides associativity between VM_ constant and mnemonic, so on changes one would have to figure out which position some flag has in this foo[] array, so I vote for not use it :-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 6:13 ` Cyrill Gorcunov @ 2012-10-23 6:30 ` Andrew Morton 2012-10-23 6:34 ` Cyrill Gorcunov 0 siblings, 1 reply; 19+ messages in thread From: Andrew Morton @ 2012-10-23 6:30 UTC (permalink / raw) To: Cyrill Gorcunov; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Tue, 23 Oct 2012 10:13:41 +0400 Cyrill Gorcunov <gorcunov@openvz.org> wrote: > On Mon, Oct 22, 2012 at 02:51:58PM -0700, Andrew Morton wrote: > ... > > > + __seq_show_vmflag(VM_DONTEXPAND,"de "); > > > + __seq_show_vmflag(VM_ACCOUNT, "ac "); > > > + __seq_show_vmflag(VM_NORESERVE, "nr "); > > > + __seq_show_vmflag(VM_HUGETLB, "ht "); > > > + __seq_show_vmflag(VM_NONLINEAR, "nl "); > > > + __seq_show_vmflag(VM_ARCH_1, "ar "); > > > + __seq_show_vmflag(VM_DONTDUMP, "dd "); > > > + __seq_show_vmflag(VM_MIXEDMAP, "mm "); > > > + __seq_show_vmflag(VM_HUGEPAGE, "hg "); > > > + __seq_show_vmflag(VM_NOHUGEPAGE,"nh "); > ... > > > > This code would be much denser if we did the old > > > > static const char foo[] = "rdwrexshmrmw..."; > > unsigned i; > > > > for (i = 0; i < BITS_PER_LONG; i++) { > > if (flags & (1 << i)) > > seq_printf("%c%c ", foo[i * 2], foo[i * 2 + 1]); > > } > > > > trick. But then we'd have to remember to fix foo[] each time we > > alter the flags, so maybe let's not do that. > > Yup, but not only that, this kind of trick hides associativity between > VM_ constant and mnemonic, so on changes one would have to figure out > which position some flag has in this foo[] array, so I vote for not > use it :-) Well you could do struct { char x[2]; } y[] = { [CLOG2(VM_DONTEXPAND)] = { 'd', 'e' }, [CLOG2(VM_ACCOUNT)] = { 'a', 'c' }, [CLOG2(VM_NORESERVE)] = { 'n', 'r' }, }; ... for (i = 0; i < BITS_PER_LONG; i++) { if (flags & (1 << i)) seq_printf("%c%c ", y[i][0], y[i][1]); } where CLOG2() is extracted from the guts of ilog2(). I'll stop now :) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 6:30 ` Andrew Morton @ 2012-10-23 6:34 ` Cyrill Gorcunov 2012-10-23 7:15 ` Cyrill Gorcunov 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-23 6:34 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Mon, Oct 22, 2012 at 11:30:25PM -0700, Andrew Morton wrote: ... > > Yup, but not only that, this kind of trick hides associativity between > > VM_ constant and mnemonic, so on changes one would have to figure out > > which position some flag has in this foo[] array, so I vote for not > > use it :-) > > Well you could do > > struct { > char x[2]; > } y[] = { > [CLOG2(VM_DONTEXPAND)] = { 'd', 'e' }, > [CLOG2(VM_ACCOUNT)] = { 'a', 'c' }, > [CLOG2(VM_NORESERVE)] = { 'n', 'r' }, > }; > > ... > > for (i = 0; i < BITS_PER_LONG; i++) { > if (flags & (1 << i)) > seq_printf("%c%c ", y[i][0], y[i][1]); > } > > where CLOG2() is extracted from the guts of ilog2(). > > I'll stop now :) Yup, this one will be a wy better. Letme try it out :) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 6:34 ` Cyrill Gorcunov @ 2012-10-23 7:15 ` Cyrill Gorcunov 2012-10-23 21:30 ` Andrew Morton 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-23 7:15 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Tue, Oct 23, 2012 at 10:34:30AM +0400, Cyrill Gorcunov wrote: > On Mon, Oct 22, 2012 at 11:30:25PM -0700, Andrew Morton wrote: > ... > > > Yup, but not only that, this kind of trick hides associativity between > > > VM_ constant and mnemonic, so on changes one would have to figure out > > > which position some flag has in this foo[] array, so I vote for not > > > use it :-) > > > > Well you could do > > > > struct { > > char x[2]; > > } y[] = { > > [CLOG2(VM_DONTEXPAND)] = { 'd', 'e' }, > > [CLOG2(VM_ACCOUNT)] = { 'a', 'c' }, > > [CLOG2(VM_NORESERVE)] = { 'n', 'r' }, > > }; > > > > ... > > > > for (i = 0; i < BITS_PER_LONG; i++) { > > if (flags & (1 << i)) > > seq_printf("%c%c ", y[i][0], y[i][1]); > > } > > > > where CLOG2() is extracted from the guts of ilog2(). > > > > I'll stop now :) > > Yup, this one will be a wy better. Letme try it out :) ilog2 works well enough here as well. --- From: Cyrill Gorcunov <gorcunov@openvz.org> Subject: procfs: add VmFlags field in smaps output v3 During c/r sessions we've found that there is no way at the moment to fetch some VMA associated flags, such as mlock() and madvise(). This leads us to a problem -- we don't know if we should call for mlock() and/or madvise() after restore on the vma area we're bringing back to life. This patch intorduces a new field into "smaps" output called VmFlags, where all set flags associated with the particular VMA is shown as two letter mnemonics. [ Strictly speaking for c/r we only need mlock/madvise bits but it has been said that providing just a few flags looks somehow inconsistent. So all flags are here now. ] This feature is made available on CONFIG_CHECKPOINT_RESTORE=n kernels, as other applications may start to use these fields. The data is encoded in a somewhat awkward two letters mnemonic form, to encourage userspace to be prepared for fields being added or removed in the future. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- Documentation/filesystems/proc.txt | 40 +++++++++++++++++++++++++++- fs/proc/task_mmu.c | 52 +++++++++++++++++++++++++++++++++++++ 2 files changed, 90 insertions(+), 2 deletions(-) Index: linux-2.6.git/Documentation/filesystems/proc.txt =================================================================== --- linux-2.6.git.orig/Documentation/filesystems/proc.txt +++ linux-2.6.git/Documentation/filesystems/proc.txt @@ -142,7 +142,7 @@ Table 1-1: Process specific entries in / pagemap Page table stack Report full stack trace, enable via CONFIG_STACKTRACE smaps a extension based on maps, showing the memory consumption of - each mapping + each mapping and flags associated with it .............................................................................. For example, to get the status information of a process, all you have to do is @@ -415,8 +415,9 @@ Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 374 kB +VmFlags: rd ex mr mw me de -The first of these lines shows the same information as is displayed for the +the first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping (size), the amount of the mapping that is currently resident in RAM (RSS), the process' proportional share of this mapping (PSS), the number of clean and @@ -430,6 +431,41 @@ and a page is modified, the file page is "Swap" shows how much would-be-anonymous memory is also used, but out on swap. +"VmFlags" field deserves a separate description. This member represents the kernel +flags associated with the particular virtual memory area in two letter encoded +manner. The codes are the following: + rd - readable + wr - writeable + ex - executable + sh - shared + mr - may read + mw - may write + me - may execute + ms - may share + gd - stack segment growns down + pf - pure PFN range + dw - disabled write to the mapped file + lo - pages are locked in memory + io - memory mapped I/O area + sr - sequential read advise provided + rr - random read advise provided + dc - do not copy area on fork + de - do not expand area on remapping + ac - area is accountable + nr - swap space is not reserved for the area + ht - area uses huge tlb pages + nl - non-linear mapping + ar - architecture specific flag + dd - do not include area into core dump + mm - mixed map area + hg - huge page advise flag + nh - no-huge page advise flag + mg - mergable advise flag + +Note that there is no guarantee that every flag and associated mnemonic will +be present in all further kernel releases. Things get changed, the flags may +be vanished or the reverse -- new added. + This file is only present if the CONFIG_MMU kernel configuration option is enabled. Index: linux-2.6.git/fs/proc/task_mmu.c =================================================================== --- linux-2.6.git.orig/fs/proc/task_mmu.c +++ linux-2.6.git/fs/proc/task_mmu.c @@ -480,6 +480,56 @@ static int smaps_pte_range(pmd_t *pmd, u return 0; } +static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) +{ + /* + * Don't forget to update Documentation/ on changes. + */ + + const struct { + const char l[2]; + } mnemonics[BITS_PER_LONG] = { + [ilog2(VM_READ)] = { .l = {'r', 'd'} }, + [ilog2(VM_WRITE)] = { .l = {'w', 'r'} }, + [ilog2(VM_EXEC)] = { .l = {'e', 'x'} }, + [ilog2(VM_SHARED)] = { .l = {'s', 'h'} }, + [ilog2(VM_MAYREAD)] = { .l = {'m', 'r'} }, + [ilog2(VM_MAYWRITE)] = { .l = {'m', 'w'} }, + [ilog2(VM_MAYEXEC)] = { .l = {'m', 'e'} }, + [ilog2(VM_MAYSHARE)] = { .l = {'m', 's'} }, + [ilog2(VM_GROWSDOWN)] = { .l = {'g', 'd'} }, + [ilog2(VM_PFNMAP)] = { .l = {'p', 'f'} }, + [ilog2(VM_DENYWRITE)] = { .l = {'d', 'w'} }, + [ilog2(VM_LOCKED)] = { .l = {'l', 'o'} }, + [ilog2(VM_IO)] = { .l = {'i', 'o'} }, + [ilog2(VM_SEQ_READ)] = { .l = {'s', 'r'} }, + [ilog2(VM_RAND_READ)] = { .l = {'r', 'r'} }, + [ilog2(VM_DONTCOPY)] = { .l = {'d', 'c'} }, + [ilog2(VM_DONTEXPAND)] = { .l = {'d', 'e'} }, + [ilog2(VM_ACCOUNT)] = { .l = {'a', 'c'} }, + [ilog2(VM_NORESERVE)] = { .l = {'n', 'r'} }, + [ilog2(VM_HUGETLB)] = { .l = {'h', 't'} }, + [ilog2(VM_NONLINEAR)] = { .l = {'n', 'l'} }, + [ilog2(VM_ARCH_1)] = { .l = {'a', 'r'} }, + [ilog2(VM_DONTDUMP)] = { .l = {'d', 'd'} }, + [ilog2(VM_MIXEDMAP)] = { .l = {'m', 'm'} }, + [ilog2(VM_HUGEPAGE)] = { .l = {'h', 'g'} }, + [ilog2(VM_NOHUGEPAGE)] = { .l = {'n', 'h'} }, + [ilog2(VM_MERGEABLE)] = { .l = {'m', 'g'} }, + }; + + size_t i; + + seq_puts(m, "VmFlags: "); + for (i = 0; i < BITS_PER_LONG; i++) { + if (vma->vm_flags & (1 << i)) + seq_printf(m, "%c%c ", + mnemonics[i].l[0], + mnemonics[i].l[1]); + } + seq_putc(m, '\n'); +} + static int show_smap(struct seq_file *m, void *v, int is_pid) { struct proc_maps_private *priv = m->private; @@ -535,6 +585,8 @@ static int show_smap(struct seq_file *m, seq_printf(m, "Nonlinear: %8lu kB\n", mss.nonlinear >> 10); + show_smap_vma_flags(m, vma); + if (m->count < m->size) /* vma is copied successfully */ m->version = (vma != get_gate_vma(task->mm)) ? vma->vm_start : 0; ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 7:15 ` Cyrill Gorcunov @ 2012-10-23 21:30 ` Andrew Morton 2012-10-23 21:46 ` Cyrill Gorcunov 0 siblings, 1 reply; 19+ messages in thread From: Andrew Morton @ 2012-10-23 21:30 UTC (permalink / raw) To: Cyrill Gorcunov; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Tue, 23 Oct 2012 11:15:49 +0400 Cyrill Gorcunov <gorcunov@openvz.org> wrote: > On Tue, Oct 23, 2012 at 10:34:30AM +0400, Cyrill Gorcunov wrote: > > On Mon, Oct 22, 2012 at 11:30:25PM -0700, Andrew Morton wrote: > > ... > > > > Yup, but not only that, this kind of trick hides associativity between > > > > VM_ constant and mnemonic, so on changes one would have to figure out > > > > which position some flag has in this foo[] array, so I vote for not > > > > use it :-) > > > > > > Well you could do > > > > > > struct { > > > char x[2]; > > > } y[] = { > > > [CLOG2(VM_DONTEXPAND)] = { 'd', 'e' }, > > > [CLOG2(VM_ACCOUNT)] = { 'a', 'c' }, > > > [CLOG2(VM_NORESERVE)] = { 'n', 'r' }, > > > }; > > > > > > ... > > > > > > for (i = 0; i < BITS_PER_LONG; i++) { > > > if (flags & (1 << i)) > > > seq_printf("%c%c ", y[i][0], y[i][1]); > > > } > > > > > > where CLOG2() is extracted from the guts of ilog2(). > > > > > > I'll stop now :) > > > > Yup, this one will be a wy better. Letme try it out :) > > ilog2 works well enough here as well. > --- > From: Cyrill Gorcunov <gorcunov@openvz.org> > Subject: procfs: add VmFlags field in smaps output v3 > > During c/r sessions we've found that there is no way at the moment to > fetch some VMA associated flags, such as mlock() and madvise(). > > This leads us to a problem -- we don't know if we should call for > mlock() and/or madvise() after restore on the vma area we're bringing > back to life. > > This patch intorduces a new field into "smaps" output called VmFlags, > where all set flags associated with the particular VMA is shown as two > letter mnemonics. > > [ Strictly speaking for c/r we only need mlock/madvise bits but it has been > said that providing just a few flags looks somehow inconsistent. So all > flags are here now. ] > > This feature is made available on CONFIG_CHECKPOINT_RESTORE=n kernels, as > other applications may start to use these fields. > > The data is encoded in a somewhat awkward two letters mnemonic form, to > encourage userspace to be prepared for fields being added or removed in > the future. > Wow. This version generates 1k less kernel bloat than v2! Gee, and I only sent that email as a late-night joke ;) fs/proc/task_mmu.o with neither patch: text data bss dec hex filename 14849 112 5312 20273 4f31 fs/proc/task_mmu.o fs/proc/task_mmu.o with the v2 patch: 16074 112 5776 21962 55ca fs/proc/task_mmu.o fs/proc/task_mmu.o with the v3 patch: 15446 112 5368 20926 51be fs/proc/task_mmu.o fs/proc/task_mmu.o with the v3 patch and the below fix: 15123 112 5352 20587 506b fs/proc/task_mmu.o So the delta has gone from 1700 bytes down to 300. Seems that it pays to be anal about these things ;) Don't forget the `static'! Without it, the compiler will need to construct the array as a temporary on the stack each time the function is called - it's just terrible. (There's no reason why the compiler can't insert the static for us as an optimisation, and I think later gcc's may have got smarter about this). Was there a reason why you added the ".l = " to the initialiser? My gcc is happy without it. Also... what happens if there's an unrecognised bit set in `flags'? Memory corruption or code skew could cause this. We emit a couple of NULs into the procfs output, which I guess is an OK response to such a condition. From: Andrew Morton <akpm@linux-foundation.org> Subject: procfs-add-vmflags-field-in-smaps-output-v3-fix make mnemonics[] static, remove unneeded init code, tidy whitespace Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- fs/proc/task_mmu.c | 58 ++++++++++++++++++++----------------------- 1 file changed, 28 insertions(+), 30 deletions(-) diff -puN Documentation/filesystems/proc.txt~procfs-add-vmflags-field-in-smaps-output-v3-fix Documentation/filesystems/proc.txt diff -puN fs/proc/task_mmu.c~procfs-add-vmflags-field-in-smaps-output-v3-fix fs/proc/task_mmu.c --- a/fs/proc/task_mmu.c~procfs-add-vmflags-field-in-smaps-output-v3-fix +++ a/fs/proc/task_mmu.c @@ -531,39 +531,37 @@ static void show_smap_vma_flags(struct s /* * Don't forget to update Documentation/ on changes. */ - - const struct { + static const struct { const char l[2]; } mnemonics[BITS_PER_LONG] = { - [ilog2(VM_READ)] = { .l = {'r', 'd'} }, - [ilog2(VM_WRITE)] = { .l = {'w', 'r'} }, - [ilog2(VM_EXEC)] = { .l = {'e', 'x'} }, - [ilog2(VM_SHARED)] = { .l = {'s', 'h'} }, - [ilog2(VM_MAYREAD)] = { .l = {'m', 'r'} }, - [ilog2(VM_MAYWRITE)] = { .l = {'m', 'w'} }, - [ilog2(VM_MAYEXEC)] = { .l = {'m', 'e'} }, - [ilog2(VM_MAYSHARE)] = { .l = {'m', 's'} }, - [ilog2(VM_GROWSDOWN)] = { .l = {'g', 'd'} }, - [ilog2(VM_PFNMAP)] = { .l = {'p', 'f'} }, - [ilog2(VM_DENYWRITE)] = { .l = {'d', 'w'} }, - [ilog2(VM_LOCKED)] = { .l = {'l', 'o'} }, - [ilog2(VM_IO)] = { .l = {'i', 'o'} }, - [ilog2(VM_SEQ_READ)] = { .l = {'s', 'r'} }, - [ilog2(VM_RAND_READ)] = { .l = {'r', 'r'} }, - [ilog2(VM_DONTCOPY)] = { .l = {'d', 'c'} }, - [ilog2(VM_DONTEXPAND)] = { .l = {'d', 'e'} }, - [ilog2(VM_ACCOUNT)] = { .l = {'a', 'c'} }, - [ilog2(VM_NORESERVE)] = { .l = {'n', 'r'} }, - [ilog2(VM_HUGETLB)] = { .l = {'h', 't'} }, - [ilog2(VM_NONLINEAR)] = { .l = {'n', 'l'} }, - [ilog2(VM_ARCH_1)] = { .l = {'a', 'r'} }, - [ilog2(VM_DONTDUMP)] = { .l = {'d', 'd'} }, - [ilog2(VM_MIXEDMAP)] = { .l = {'m', 'm'} }, - [ilog2(VM_HUGEPAGE)] = { .l = {'h', 'g'} }, - [ilog2(VM_NOHUGEPAGE)] = { .l = {'n', 'h'} }, - [ilog2(VM_MERGEABLE)] = { .l = {'m', 'g'} }, + [ilog2(VM_READ)] = { {'r', 'd'} }, + [ilog2(VM_WRITE)] = { {'w', 'r'} }, + [ilog2(VM_EXEC)] = { {'e', 'x'} }, + [ilog2(VM_SHARED)] = { {'s', 'h'} }, + [ilog2(VM_MAYREAD)] = { {'m', 'r'} }, + [ilog2(VM_MAYWRITE)] = { {'m', 'w'} }, + [ilog2(VM_MAYEXEC)] = { {'m', 'e'} }, + [ilog2(VM_MAYSHARE)] = { {'m', 's'} }, + [ilog2(VM_GROWSDOWN)] = { {'g', 'd'} }, + [ilog2(VM_PFNMAP)] = { {'p', 'f'} }, + [ilog2(VM_DENYWRITE)] = { {'d', 'w'} }, + [ilog2(VM_LOCKED)] = { {'l', 'o'} }, + [ilog2(VM_IO)] = { {'i', 'o'} }, + [ilog2(VM_SEQ_READ)] = { {'s', 'r'} }, + [ilog2(VM_RAND_READ)] = { {'r', 'r'} }, + [ilog2(VM_DONTCOPY)] = { {'d', 'c'} }, + [ilog2(VM_DONTEXPAND)] = { {'d', 'e'} }, + [ilog2(VM_ACCOUNT)] = { {'a', 'c'} }, + [ilog2(VM_NORESERVE)] = { {'n', 'r'} }, + [ilog2(VM_HUGETLB)] = { {'h', 't'} }, + [ilog2(VM_NONLINEAR)] = { {'n', 'l'} }, + [ilog2(VM_ARCH_1)] = { {'a', 'r'} }, + [ilog2(VM_DONTDUMP)] = { {'d', 'd'} }, + [ilog2(VM_MIXEDMAP)] = { {'m', 'm'} }, + [ilog2(VM_HUGEPAGE)] = { {'h', 'g'} }, + [ilog2(VM_NOHUGEPAGE)] = { {'n', 'h'} }, + [ilog2(VM_MERGEABLE)] = { {'m', 'g'} }, }; - size_t i; seq_puts(m, "VmFlags: "); _ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 21:30 ` Andrew Morton @ 2012-10-23 21:46 ` Cyrill Gorcunov 2012-10-23 21:59 ` Cyrill Gorcunov 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-23 21:46 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Tue, Oct 23, 2012 at 02:30:45PM -0700, Andrew Morton wrote: > > > > The data is encoded in a somewhat awkward two letters mnemonic form, to > > encourage userspace to be prepared for fields being added or removed in > > the future. > > > > Wow. This version generates 1k less kernel bloat than v2! Gee, and I > only sent that email as a late-night joke ;) Cool! > fs/proc/task_mmu.o with neither patch: > text data bss dec hex filename > 14849 112 5312 20273 4f31 fs/proc/task_mmu.o > > fs/proc/task_mmu.o with the v2 patch: > 16074 112 5776 21962 55ca fs/proc/task_mmu.o > > fs/proc/task_mmu.o with the v3 patch: > 15446 112 5368 20926 51be fs/proc/task_mmu.o > > fs/proc/task_mmu.o with the v3 patch and the below fix: > 15123 112 5352 20587 506b fs/proc/task_mmu.o > > So the delta has gone from 1700 bytes down to 300. Seems that it pays > to be anal about these things ;) LOL ;-) > Don't forget the `static'! Without it, the compiler will need to Yeah, for some reason missed it, thanks! > construct the array as a temporary on the stack each time the function > is called - it's just terrible. (There's no reason why the compiler > can't insert the static for us as an optimisation, and I think later > gcc's may have got smarter about this). > > Was there a reason why you added the ".l = " to the initialiser? My > gcc is happy without it. Mine either, just as habbit I would say, thanks. > Also... what happens if there's an unrecognised bit set in `flags'? > Memory corruption or code skew could cause this. We emit a couple of > NULs into the procfs output, which I guess is an OK response to such a > condition. That's indeed will produce some nil character on the screen. I guess we need some designited init here, say [0 ... (BITS_PER_LONG-1)] = { {'-', '-'} }, ... [ilog2(VM_READ)] = { {'r', 'd'} }, ... and so on, i'll update on top > From: Andrew Morton <akpm@linux-foundation.org> > Subject: procfs-add-vmflags-field-in-smaps-output-v3-fix > > make mnemonics[] static, remove unneeded init code, tidy whitespace > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 21:46 ` Cyrill Gorcunov @ 2012-10-23 21:59 ` Cyrill Gorcunov 2012-10-23 22:32 ` Peter Zijlstra 0 siblings, 1 reply; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-23 21:59 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Emelyanov, LKML, Peter Zijlstra On Wed, Oct 24, 2012 at 01:46:39AM +0400, Cyrill Gorcunov wrote: > > > Also... what happens if there's an unrecognised bit set in `flags'? > > Memory corruption or code skew could cause this. We emit a couple of > > NULs into the procfs output, which I guess is an OK response to such a > > condition. > > That's indeed will produce some nil character on the screen. I guess we > need some designited init here, say > > [0 ... (BITS_PER_LONG-1)] = { {'-', '-'} }, > ... > [ilog2(VM_READ)] = { {'r', 'd'} }, > ... > and so on, i'll update on top > Andrew, could you please fold it on top of your procfs-add-vmflags-field-in-smaps-output-v3-fix ? (If this is inconvenient -- just give me a word and I'll squash everything in one new patch instead). --- From: Cyrill Gorcunov <gorcunov@openvz.org> Subject: procfs-add-vmflags-field-in-smaps-output-v3-fix-on-top Use designated init to assign "??" mnemonic on unknown flags. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Andrew Morton <akpm@linux-foundation.org> --- fs/proc/task_mmu.c | 5 +++++ 1 file changed, 5 insertions(+) Index: linux-2.6.git/fs/proc/task_mmu.c =================================================================== --- linux-2.6.git.orig/fs/proc/task_mmu.c +++ linux-2.6.git/fs/proc/task_mmu.c @@ -488,6 +488,11 @@ static void show_smap_vma_flags(struct s static const struct { const char l[2]; } mnemonics[BITS_PER_LONG] = { + /* + * In case if we meet a flag we don't know about. + */ + [0 ... (BITS_PER_LONG-1)] = { {'?', '?'} }, + [ilog2(VM_READ)] = { {'r', 'd'} }, [ilog2(VM_WRITE)] = { {'w', 'r'} }, [ilog2(VM_EXEC)] = { {'e', 'x'} }, ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 21:59 ` Cyrill Gorcunov @ 2012-10-23 22:32 ` Peter Zijlstra 2012-10-23 23:56 ` Stephen Rothwell 2012-10-24 6:30 ` Cyrill Gorcunov 0 siblings, 2 replies; 19+ messages in thread From: Peter Zijlstra @ 2012-10-23 22:32 UTC (permalink / raw) To: Cyrill Gorcunov; +Cc: Andrew Morton, Pavel Emelyanov, LKML On Wed, 2012-10-24 at 01:59 +0400, Cyrill Gorcunov wrote: > [ilog2(VM_WRITE)] = { {'w', 'r'} }, since we're being awfully positive about crazy late night ideas, how about something like: #define MNEM(_VM, _mn) [ilog2(_VM)] = {(const char [2]){_mn}} MNEM(VM_WRITE, "wr"), ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 22:32 ` Peter Zijlstra @ 2012-10-23 23:56 ` Stephen Rothwell 2012-10-24 6:30 ` Cyrill Gorcunov 1 sibling, 0 replies; 19+ messages in thread From: Stephen Rothwell @ 2012-10-23 23:56 UTC (permalink / raw) To: Peter Zijlstra; +Cc: Cyrill Gorcunov, Andrew Morton, Pavel Emelyanov, LKML [-- Attachment #1: Type: text/plain, Size: 766 bytes --] On Wed, 24 Oct 2012 00:32:54 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > On Wed, 2012-10-24 at 01:59 +0400, Cyrill Gorcunov wrote: > > [ilog2(VM_WRITE)] = { {'w', 'r'} }, > > since we're being awfully positive about crazy late night ideas, how > about something like: > > #define MNEM(_VM, _mn) [ilog2(_VM)] = {(const char [2]){_mn}} > > MNEM(VM_WRITE, "wr"), The C standard and gcc allow you to initialise the 2 character array with a (>=2 character) string literal with no casting, so #define MNEM(_VM, _mn) [ilog2(_VM)] = {_mn} should work. [ and the the earlier version, [ilog2(VM_READ)] = { "rd" }, etc, does work. ] -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [rfc 0/2] Introducing VmFlags field into smaps output 2012-10-23 22:32 ` Peter Zijlstra 2012-10-23 23:56 ` Stephen Rothwell @ 2012-10-24 6:30 ` Cyrill Gorcunov 1 sibling, 0 replies; 19+ messages in thread From: Cyrill Gorcunov @ 2012-10-24 6:30 UTC (permalink / raw) To: Peter Zijlstra; +Cc: Andrew Morton, Pavel Emelyanov, LKML On Wed, Oct 24, 2012 at 12:32:54AM +0200, Peter Zijlstra wrote: > On Wed, 2012-10-24 at 01:59 +0400, Cyrill Gorcunov wrote: > > [ilog2(VM_WRITE)] = { {'w', 'r'} }, > > since we're being awfully positive about crazy late night ideas, how > about something like: > > #define MNEM(_VM, _mn) [ilog2(_VM)] = {(const char [2]){_mn}} > > MNEM(VM_WRITE, "wr"), I see no reason why should not we :) I'll update. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-10-24 6:30 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-22 19:14 [rfc 0/2] Introducing VmFlags field into smaps output Cyrill Gorcunov 2012-10-22 19:14 ` [rfc 1/2] [RFC] procfs: Add VmFlags field in " Cyrill Gorcunov 2012-10-22 19:14 ` [rfc 2/2] [RFC] procfs: Documantation -- Add VmFlags field description Cyrill Gorcunov 2012-10-22 19:29 ` [rfc 0/2] Introducing VmFlags field into smaps output Andrew Morton 2012-10-22 19:39 ` Cyrill Gorcunov 2012-10-22 20:50 ` Pavel Emelyanov 2012-10-22 20:56 ` Cyrill Gorcunov 2012-10-22 21:34 ` Cyrill Gorcunov 2012-10-22 21:51 ` Andrew Morton 2012-10-23 6:13 ` Cyrill Gorcunov 2012-10-23 6:30 ` Andrew Morton 2012-10-23 6:34 ` Cyrill Gorcunov 2012-10-23 7:15 ` Cyrill Gorcunov 2012-10-23 21:30 ` Andrew Morton 2012-10-23 21:46 ` Cyrill Gorcunov 2012-10-23 21:59 ` Cyrill Gorcunov 2012-10-23 22:32 ` Peter Zijlstra 2012-10-23 23:56 ` Stephen Rothwell 2012-10-24 6:30 ` Cyrill Gorcunov
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.