linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Jann Horn <jann@thejh.net>,
	linux-mm@kvack.org
Subject: Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time
Date: Mon, 22 Aug 2016 01:00:59 -0700	[thread overview]
Message-ID: <1471852859.3746.42.camel@perches.com> (raw)
In-Reply-To: <20160822072414.GB13596@dhcp22.suse.cz>

On Mon, 2016-08-22 at 09:24 +0200, Michal Hocko wrote:
> On Sat 20-08-16 01:00:17, Joe Perches wrote:
> [...]
> > 
> >  static int proc_maps_open(struct inode *inode, struct file *file,
> >  			const struct seq_operations *ops, int psize)
> >  {
> > -	struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
> > +	struct proc_maps_private *priv;
> > +	struct mm_struct *mm;
> > +
> > +	mm = proc_mem_open(inode, PTRACE_MODE_READ);
> > +	if (IS_ERR(mm))
> > +		return PTR_ERR(mm);
> >  
> > +	priv = __seq_open_private_bufsize(file, ops, psize,
> > +					  mm && mm->map_count ?
> > +					  mm->map_count * 0x300 : PAGE_SIZE);
> NAK to this!
>
> Seriously, this just gives any random user access to user
> defined amount of memory which not accounted, not reclaimable and a
> potential consumer of any higher order blocks.

I completely disagree here with your rationale here.

I think you didn't read the code and didn't try it either.

This code is identical to the previous code but it
simply estimates the required output size first.

> Besides that, at least one show_smap output will always fit inside the
> single page and AFAIR (it's been quite a while since I've looked into
> seq_file internals) the buffer grows only when the single show doesn't
> fit in.

It's never been like that as far as I know.

Please read fs/seq_file.c:traverse()

This code starts with a PAGE_SIZE block of memory then if
the complete output doesn't fit, stops, frees that block
of memory, and retries the complete output with a last block
size allocated << 1 and tries again.

> I really do not understand why you insist on code duplication rather
> than reuse but if you really insist then just make this (without the
> above __seq_open_private_bufsize, re-measure and add the results to the
> changelog and repost.

I've tried it, I wish you would.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-08-22  8:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-18 11:31 [PATCH] proc, smaps: reduce printing overhead Michal Hocko
2016-08-18 13:26 ` Joe Perches
2016-08-18 14:26   ` Michal Hocko
2016-08-18 14:41     ` Joe Perches
2016-08-18 14:41     ` Michal Hocko
2016-08-18 14:46       ` Joe Perches
2016-08-18 14:58         ` Michal Hocko
2016-08-18 15:23           ` Joe Perches
2016-08-18 16:42             ` Michal Hocko
2016-08-19 10:12 ` [PATCH 0/2] fs, proc: optimize smaps output formatting Michal Hocko
2016-08-19 10:12   ` [PATCH 1/2] proc, meminfo: abstract show_val_kb Michal Hocko
2016-08-26  2:54     ` [lkp] [proc, meminfo] dd3b422c11: stderr.Signal#(FPE)caught_by_ps(procps-ng_version#) kernel test robot
2016-08-19 10:13   ` [PATCH 2/2] proc, smaps: reduce printing overhead Michal Hocko
2016-08-19 17:43   ` [PATCH 0/2] fs, proc: optimize smaps output formatting Joe Perches
2016-08-19 20:18     ` Joe Perches
2016-08-20  7:29     ` Michal Hocko
2016-08-20  7:55       ` Joe Perches
2016-08-20  8:00       ` [PATCH 0/2] seq: Speed up /proc/<pid>/smaps Joe Perches
2016-08-20  8:00         ` [PATCH 1/2] seq_file: Add __seq_open_private_bufsize for seq file_operation sizes Joe Perches
2016-08-20  8:00         ` [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time Joe Perches
2016-08-22  7:24           ` Michal Hocko
2016-08-22  8:00             ` Joe Perches [this message]
2016-08-22  8:30               ` Joe Perches
2016-08-22 12:09                 ` Michal Hocko
2016-08-23 15:14 ` [PATCH] proc, smaps: reduce printing overhead Michal Hocko

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=1471852859.3746.42.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=jann@thejh.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox