All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Pavel Emelyanov <xemul@parallels.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [rfc 0/2] Introducing VmFlags field into smaps output
Date: Wed, 24 Oct 2012 01:46:39 +0400	[thread overview]
Message-ID: <20121023214639.GM7020@moon> (raw)
In-Reply-To: <20121023143045.183657c4.akpm@linux-foundation.org>

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
> 

  reply	other threads:[~2012-10-23 21:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121023214639.GM7020@moon \
    --to=gorcunov@openvz.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.