[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGqmi74gpvJv8=B-3pVSMrDssu-aYMxW9xM7mt1WNQjGLjMZqA@mail.gmail.com>
Date: Tue, 13 Nov 2018 21:17:42 +0300
From: Timofey Titovets <timofey.titovets@...esis.ru>
To: pasha.tatashin@...een.com
Cc: oleksandr@...alenko.name, Jann Horn <jannh@...gle.com>,
linux-doc@...r.kernel.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH V3] KSM: allow dedup all tasks memory
вт, 13 нояб. 2018 г. в 20:59, Pavel Tatashin <pasha.tatashin@...een.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.
And same for THP
(because currently apps just refuse to start if THP enabled, because of no way
to forbid thp).
Thanks.
> >
> > > As far as I know, basically nobody is using KSM at this point. There
> > > are blog posts from several cloud providers about these security risks
> > > that explicitly state that they're not using memory deduplication.
> >
> > I tend to disagree here. Based on both what my company does and what UKSM
> > users do, memory dedup is a desired option (note "option" word here, not the
> > default choice).
>
> Lightweight containers is a use case for KSM: when many VMs share the
> same small kernel. KSM is used in production by large cloud vendors.
>
> Thank you,
> Pasha
>
Powered by blists - more mailing lists