From: Michal Hocko <mhocko@kernel.org>
To: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: linux-kernel@vger.kernel.org, Kirill Tkhai <ktkhai@virtuozzo.com>,
Vlastimil Babka <vbabka@suse.cz>,
Matthew Wilcox <willy@infradead.org>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Timofey Titovets <nefelim4ag@gmail.com>,
Aaron Tomlin <atomlin@redhat.com>,
Grzegorz Halat <ghalat@redhat.com>,
linux-mm@kvack.org, linux-api@vger.kernel.org,
Hugh Dickins <hughd@google.com>,
Suren Baghdasaryan <surenb@google.com>,
Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH RFC v2 0/4] mm/ksm: add option to automerge VMAs
Date: Wed, 15 May 2019 16:51:51 +0200 [thread overview]
Message-ID: <20190515145151.GG16651@dhcp22.suse.cz> (raw)
In-Reply-To: <20190515065311.GB16651@dhcp22.suse.cz>
[Cc Suren and Minchan - the email thread starts here 20190514131654.25463-1-oleksandr@redhat.com]
On Wed 15-05-19 08:53:11, Michal Hocko wrote:
[...]
> I will try to comment on the interface itself later. But I have to say
> that I am not impressed. Abusing sysfs for per process features is quite
> gross to be honest.
I have already commented on this in other email. I consider sysfs an
unsuitable interface for per-process API. Not to mention this particular
one is very KSM specific while the question about setting different
hints on memory of a remote process is a more generic question. As
already mentioned there are usecases where people would like to say
that a certain memory is cold from outside of the process context (e.g.
monitor application). So essentially a form of a user space memory
management. And this usecase sounds a bit similar to me and having a
common api sounds more sensible to me.
One thing we were discussing at LSFMM this year was a way to either
provide madvise_remote(pid, addr, length, advice) or a fadvise
alternative over /proc/<pid>/map_vmas/<range> file descriptors
(essentially resembling the existing map_files api) to achieve such a
functionality. This is still a very rough idea but the api would sound
much more generic to me and it would allow much wider range of usecases.
But maybe I am completely wrong and this is just opens a can of worms
that we do not want.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-05-15 14:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 13:16 [PATCH RFC v2 0/4] mm/ksm: add option to automerge VMAs Oleksandr Natalenko
2019-05-14 13:16 ` [PATCH RFC v2 1/4] mm/ksm: introduce ksm_enter() helper Oleksandr Natalenko
2019-05-14 13:16 ` [PATCH RFC v2 2/4] mm/ksm: introduce ksm_leave() helper Oleksandr Natalenko
2019-05-14 13:16 ` [PATCH RFC v2 3/4] mm/ksm: introduce force_madvise knob Oleksandr Natalenko
2019-05-14 13:22 ` Aaron Tomlin
2019-05-15 0:48 ` Timofey Titovets
2019-05-14 13:16 ` [PATCH RFC v2 4/4] mm/ksm: add force merging/unmerging documentation Oleksandr Natalenko
2019-05-15 0:53 ` Timofey Titovets
2019-05-15 6:26 ` Oleksandr Natalenko
2019-05-14 14:41 ` [PATCH RFC v2 0/4] mm/ksm: add option to automerge VMAs Michal Hocko
2019-05-14 14:51 ` Michal Hocko
2019-05-15 6:25 ` Oleksandr Natalenko
2019-05-15 6:53 ` Michal Hocko
2019-05-15 7:37 ` Oleksandr Natalenko
2019-05-15 8:33 ` Michal Hocko
2019-05-15 8:51 ` Oleksandr Natalenko
2019-05-15 14:24 ` Michal Hocko
2019-05-15 14:51 ` Michal Hocko [this message]
2019-05-15 15:15 ` Greg KH
2019-05-16 7:47 ` Michal Hocko
2019-05-16 7:53 ` Greg KH
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=20190515145151.GG16651@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=atomlin@redhat.com \
--cc=ghalat@redhat.com \
--cc=hughd@google.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=nefelim4ag@gmail.com \
--cc=oleksandr@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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.