All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Balbir Singh <bsingharora@gmail.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>, linux-mm <linux-mm@kvack.org>
Subject: Re: [rfc 2/2] smaps: Show zone device memory used
Date: Mon, 23 Oct 2017 11:36:45 +0200	[thread overview]
Message-ID: <20171023093645.z7b3id3ny6c4vovf@dhcp22.suse.cz> (raw)
In-Reply-To: <CAKTCnz=n3CFEhYb=WOENPB6ENrLoMg4_hRP2Tc70GLjc8aMVhg@mail.gmail.com>

On Mon 23-10-17 20:32:25, Balbir Singh wrote:
> On Mon, Oct 23, 2017 at 7:49 PM, Michal Hocko <mhocko@suse.com> wrote:
> > On Sat 21-10-17 08:55:59, Balbir Singh wrote:
> >> On Sat, Oct 21, 2017 at 12:08 AM, Michal Hocko <mhocko@suse.com> wrote:
> >> > On Wed 18-10-17 17:31:23, Balbir Singh wrote:
> >> >> With HMM, we can have either public or private zone
> >> >> device pages. With private zone device pages, they should
> >> >> show up as swapped entities. For public zone device pages
> >> >> the smaps output can be confusing and incomplete.
> >> >>
> >> >> This patch adds a new attribute to just smaps to show
> >> >> device memory usage.
> >> >
> >> > As this will become user API which we will have to maintain for ever I
> >> > would really like to hear about who is going to use this information and
> >> > what for.
> >>
> >> This is something I observed when running some tests with HMM/CDM.
> >> The issue I had was that there was no visibility of what happened to the
> >> pages after the following sequence
> >>
> >> 1. malloc/mmap pages
> >> 2. migrate_vma() to ZONE_DEVICE (hmm/cdm space)
> >> 3. look at smaps
> >>
> >> If we look at smaps after 1 and the pages are faulted in we can see the
> >> pages for the region, but at point 3, there is absolutely no visibility of
> >> what happened to the pages. I thought smaps is a good way to provide
> >> the visibility as most developers use that interface. It's more to fix the
> >> inconsistency I saw w.r.t visibility and accounting.
> >
> > Yes I can see how this can be confusing. But, well, I have grown overly
> > cautious regarding user APIs over time. So I would rather not add
> > something new until we have a real user with a usecase in mind. We can
> > always add this later but once we have exposed the accounting we are
> > bound to maintain it for ever.
> 
> I see your point. But we are beginning to build on top of this. I'll just add
> it as a private patch in my patchset. But soon, we'll need to address HMM/CDM
> pages of different sizes as well. My problem right now is to ensure correctness
> of the design and expectations and a large part of it is tracking
> where the pages are.

I would wait for more experiences to carve a userspace API into stone.
Adding one for debugging purposes is almost _always_ a bad idea that
back fires sooner or later.
-- 
Michal Hocko
SUSE Labs

--
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:[~2017-10-23  9:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  6:31 [rfc 1/2] mm/hmm: Allow smaps to see zone device public pages Balbir Singh
2017-10-18  6:31 ` [rfc 2/2] smaps: Show zone device memory used Balbir Singh
2017-10-18  7:10   ` Anshuman Khandual
2017-10-18 19:48     ` Balbir Singh
2017-10-19 17:02       ` Jerome Glisse
2017-10-21  1:23         ` Balbir Singh
2017-10-20 13:08   ` Michal Hocko
2017-10-20 21:55     ` Balbir Singh
2017-10-23  8:49       ` Michal Hocko
2017-10-23  9:32         ` Balbir Singh
2017-10-23  9:36           ` Michal Hocko [this message]
2017-10-23  9:37             ` Balbir Singh
2017-10-18  6:56 ` [rfc 1/2] mm/hmm: Allow smaps to see zone device public pages Anshuman Khandual
2017-10-18 19:36   ` Balbir Singh
2017-10-20 13:11 ` Michal Hocko
2017-10-20 21:52   ` Balbir Singh
2017-10-23  8:52     ` 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=20171023093645.z7b3id3ny6c4vovf@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=bsingharora@gmail.com \
    --cc=jglisse@redhat.com \
    --cc=linux-mm@kvack.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 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.