From: Timofey Titovets <timofey.titovets@synesis.ru>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>,
Jann Horn <jannh@google.com>,
linux-doc@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH V3] KSM: allow dedup all tasks memory
Date: Wed, 14 Nov 2018 01:40:10 +0300 [thread overview]
Message-ID: <CAGqmi77JMyxU9L4bZHPv4Nt=tyQsEZDQcMVMRfQ7de_LjZg+-Q@mail.gmail.com> (raw)
In-Reply-To: <20181113191653.btbzobquxtwt47z4@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net>
вт, 13 нояб. 2018 г. в 22:17, Pavel Tatashin <pasha.tatashin@soleen.com>:
>
> On 18-11-13 21:54:13, Timofey Titovets wrote:
> > вт, 13 нояб. 2018 г. в 21:35, Pavel Tatashin <pasha.tatashin@soleen.com>:
> > >
> > > On 18-11-13 21:17:42, Timofey Titovets wrote:
> > > > вт, 13 нояб. 2018 г. в 20:59, Pavel Tatashin <pasha.tatashin@soleen.com>:
> > > > >
> > > > > On 18-11-13 15:23:50, Oleksandr Natalenko wrote:
> > > > > > Hi.
> > > > > >
> > > > > > > Yep. However, so far, it requires an application to explicitly opt in
> > > > > > > to this behavior, so it's not all that bad. Your patch would remove
> > > > > > > the requirement for application opt-in, which, in my opinion, makes
> > > > > > > this way worse and reduces the number of applications for which this
> > > > > > > is acceptable.
> > > > > >
> > > > > > The default is to maintain the old behaviour, so unless the explicit
> > > > > > decision is made by the administrator, no extra risk is imposed.
> > > > >
> > > > > The new interface would be more tolerable if it honored MADV_UNMERGEABLE:
> > > > >
> > > > > KSM default on: merge everything except when MADV_UNMERGEABLE is
> > > > > excplicitly set.
> > > > >
> > > > > KSM default off: merge only when MADV_MERGEABLE is set.
> > > > >
> > > > > The proposed change won't honor MADV_UNMERGEABLE, meaning that
> > > > > application programmers won't have a way to prevent sensitive data to be
> > > > > every merged. So, I think, we should keep allow an explicit opt-out
> > > > > option for applications.
> > > > >
> > > >
> > > > We just did not have VM/Madvise flag for that currently.
> > > > Same as THP.
> > > > Because all logic written with assumption, what we have exactly 2 states.
> > > > Allow/Disallow (More like not allow).
> > > >
> > > > And if we try to add, that must be something like:
> > > > MADV_FORBID_* to disallow something completely.
> > >
> > > No need to add new user flag MADV_FORBID, we should keep MADV_MERGEABLE
> > > and MADV_UNMERGEABLE, but make them work so when MADV_UNMERGEABLE is
> > > set, memory is indeed becomes always unmergeable regardless of ksm mode
> > > of operation.
> > >
> > > To do the above in ksm_madvise(), a new state should be added, for example
> > > instead of:
> > >
> > > case MADV_UNMERGEABLE:
> > > *vm_flags &= ~VM_MERGEABLE;
> > >
> > > A new flag should be used:
> > > *vm_flags |= VM_UNMERGEABLE;
> > >
> > > I think, without honoring MADV_UNMERGEABLE correctly, this patch won't
> > > be accepted.
> > >
> > > Pasha
> > >
> >
> > That must work, but we out of bit space in vm_flags [1].
> > i.e. first 32 bits already defined, and other only accessible only on
> > 64-bit machines.
>
> So, grow vm_flags_t to 64-bit, or enable this feature on 64-bit only.
With all due respect to you, for that type of things we need
mm maintainer opinion.
I just don't want get situation, where after touch of other subsystems,
maintainer will just refuse that work by some reason.
i.e. writing patches for upstream (from my point of view),
is more art of communication and making resulte code acceptable by community.
Because any code which written correctly from engineering point of view,
can be easy refused, just because someone not found it useful.
Thanks.
> >
> > 1. https://elixir.bootlin.com/linux/latest/source/include/linux/mm.h#L219
next prev parent reply other threads:[~2018-11-13 22:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<CAG48ez0ZprqUYGZFxcrY6U3Dnwt77q1NJXzzpsn1XNkRuXVppw@mail.gmail.com>
2018-11-13 14:23 ` Oleksandr Natalenko
2018-11-13 17:59 ` Pavel Tatashin
2018-11-13 18:17 ` Timofey Titovets
2018-11-13 18:35 ` Pavel Tatashin
2018-11-13 18:54 ` Timofey Titovets
2018-11-13 19:16 ` Pavel Tatashin
2018-11-13 22:40 ` Timofey Titovets [this message]
2018-11-13 22:53 ` Pavel Tatashin
2018-11-13 23:07 ` Timofey Titovets
2018-11-13 20:26 ` Jann Horn
2018-11-13 22:35 ` Pavel Tatashin
2018-11-13 18:20 Timofey Titovets
[not found] <<20181112231344.7161-1-timofey.titovets@synesis.ru>
2018-11-13 11:06 ` Oleksandr Natalenko
2018-11-13 11:56 ` Timofey Titovets
2018-11-13 16:33 ` Oleksandr Natalenko
2018-11-13 17:10 ` Timofey Titovets
2018-11-13 17:27 ` Oleksandr Natalenko
2018-11-13 17:44 ` Timofey Titovets
-- strict thread matches above, loose matches on Subject: below --
2018-11-12 23:13 Timofey Titovets
2018-11-13 1:49 ` Matthew Wilcox
2018-11-13 11:25 ` Timofey Titovets
2018-11-13 2:25 ` Pavel Tatashin
2018-11-13 11:40 ` Timofey Titovets
2018-11-13 18:42 ` Pavel Tatashin
2018-11-13 22:55 ` Timofey Titovets
2018-11-13 11:57 ` Jann Horn
2018-11-13 12:58 ` Timofey Titovets
2018-11-13 13:25 ` Jann Horn
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='CAGqmi77JMyxU9L4bZHPv4Nt=tyQsEZDQcMVMRfQ7de_LjZg+-Q@mail.gmail.com' \
--to=timofey.titovets@synesis.ru \
--cc=jannh@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleksandr@natalenko.name \
--cc=pasha.tatashin@soleen.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox