From: Robert Hu <robert.hu@vmm.sh.intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>, Robert Ho <robert.hu@intel.com>,
pbonzini@redhat.com, akpm@linux-foundation.org,
dan.j.williams@intel.com, dave.hansen@intel.com,
guangrong.xiao@linux.intel.com, gleb@kernel.org,
mtosatti@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, stefanha@redhat.com,
yuhuang@redhat.com, linux-mm@kvack.org,
ross.zwisler@linux.intel.com
Subject: Re: [PATCH v3 1/2] mm, proc: Fix region lost in /proc/self/smaps
Date: Thu, 29 Sep 2016 21:14:40 +0800 [thread overview]
Message-ID: <1475154880.16655.9.camel@vmm.sh.intel.com> (raw)
In-Reply-To: <20160926084616.GA28550@dhcp22.suse.cz>
On Mon, 2016-09-26 at 10:46 +0200, Michal Hocko wrote:
> On Fri 23-09-16 17:53:51, Oleg Nesterov wrote:
> > On 09/23, Michal Hocko wrote:
> > >
> > > On Fri 23-09-16 15:56:36, Oleg Nesterov wrote:
> > > >
> > > > I think we can simplify this patch. And imo make it better. How about
> > >
> > > it is certainly less subtle because it doesn't report "sub-vmas".
> > >
> > > > if (last_addr) {
> > > > vma = find_vma(mm, last_addr - 1);
> > > > if (vma && vma->vm_start <= last_addr)
> > > > vma = m_next_vma(priv, vma);
> > > > if (vma)
> > > > return vma;
> > > > }
> > >
> > > we would still miss a VMA if the last one got shrunk/split
> >
> > Not sure I understand what you mean... If the last one was split
> > we probably should not report the new vma.
>
> Right, VMA split is less of a problem. I meant to say that if the
> last_vma->vm_end got lower for whatever reason then we could miss a VMA
> right after. We actually might want to display such a VMA because it
> could be a completely new one. We just do not know whether it is a
> former split with enlarged VMA or a completely new one
>
> [ old VMA ] Hole [ VMA ]
> [ old VMA ][ New VMa ] [ VMA ]
This is indeed possible. But I see this is like the last_vma enlargement
case. I suggest we accept such missing, as we accept the enlargement
part of last_vma is not printed.
How about we set such target: 1) no duplicate print; 2) no old vma
missing (unless it's unmapped); 3) monotonic printing.
We accept those newly added/changed parts between 2 partial reads is not
printed.
How about above suggestion? If you, Dave, Oleg and others accept it,
then Oleg's improvement can achieve it, I think.
>
> > Nevermind, in any case yes, sure, this can't "fix" other corner cases.
>
> Agreed, or at least I do not see an easy way for that.
--
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>
next prev parent reply other threads:[~2016-09-29 13:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 13:12 [PATCH v3 1/2] mm, proc: Fix region lost in /proc/self/smaps Robert Ho
2016-09-23 13:12 ` Robert Ho
2016-09-23 13:12 ` [PATCH v3 2/2] Documentation/filesystems/proc.txt: Add more description for maps/smaps Robert Ho
2016-09-23 13:12 ` Robert Ho
2016-09-23 16:06 ` Dave Hansen
2016-09-23 16:06 ` Dave Hansen
2016-09-28 2:27 ` Robert Hu
2016-09-23 13:50 ` [PATCH v3 1/2] mm, proc: Fix region lost in /proc/self/smaps Michal Hocko
2016-09-23 13:50 ` Michal Hocko
2016-09-23 14:39 ` Michal Hocko
2016-09-23 14:39 ` Michal Hocko
2016-09-23 13:56 ` Oleg Nesterov
2016-09-23 13:56 ` Oleg Nesterov
2016-09-23 14:53 ` Michal Hocko
2016-09-23 14:53 ` Michal Hocko
2016-09-23 15:53 ` Oleg Nesterov
2016-09-23 15:53 ` Oleg Nesterov
2016-09-26 8:46 ` Michal Hocko
2016-09-26 8:46 ` Michal Hocko
2016-09-29 13:14 ` Robert Hu [this message]
2016-09-29 13:42 ` Michal Hocko
2016-09-29 13:42 ` Michal Hocko
2016-09-29 13:05 ` Robert Hu
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=1475154880.16655.9.camel@vmm.sh.intel.com \
--to=robert.hu@vmm.sh.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mtosatti@redhat.com \
--cc=oleg@redhat.com \
--cc=pbonzini@redhat.com \
--cc=robert.hu@intel.com \
--cc=ross.zwisler@linux.intel.com \
--cc=stefanha@redhat.com \
--cc=yuhuang@redhat.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.