[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a62a1fed-252b-f4c8-8abb-0e4468f50fe8@gmail.com>
Date: Tue, 30 Oct 2018 23:55:46 +0200
From: Igor Stoppa <igor.stoppa@...il.com>
To: Matthew Wilcox <willy@...radead.org>,
Andy Lutomirski <luto@...capital.net>
Cc: nadav.amit@...il.com, Kees Cook <keescook@...omium.org>,
Peter Zijlstra <peterz@...radead.org>, Mimi Zohar
<zohar@...ux.vnet.ibm.com>, Dave Chinner <david@...morbit.com>,
James Morris <jmorris@...ei.org>, Michal Hocko <mhocko@...nel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-integrity <linux-integrity@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
Igor Stoppa <igor.stoppa@...wei.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, Jonathan Corbet <corbet@....net>,
Laura Abbott <labbott@...hat.com>, Randy Dunlap <rdunlap@...radead.org>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/17] prmem: documentation
On 30/10/2018 23:25, Matthew Wilcox wrote:
> On Tue, Oct 30, 2018 at 11:51:17AM -0700, Andy Lutomirski wrote:
>> Finally, one issue: rare_alloc() is going to utterly suck
>> performance-wise due to the global IPI when the region gets zapped out
>> of the direct map or otherwise made RO. This is the same issue that
>> makes all existing XPO efforts so painful. We need to either optimize
>> the crap out of it somehow or we need to make sure it’s not called
>> except during rare events like device enumeration.
>
> Batching operations is kind of the whole point of the VM ;-) Either
> this rare memory gets used a lot, in which case we'll want to create slab
> caches for it, make it a MM zone and the whole nine yeards, or it's not
> used very much in which case it doesn't matter that performance sucks.
>
> For now, I'd suggest allocating 2MB chunks as needed, and having a
> shrinker to hand back any unused pieces.
One of the prime candidates for this sort of protection is IMA.
In the IMA case, there are ever-growing lists which are populated when
accessing files.
It's something that ends up on the critical path of any usual
performance critical use case, when accessing files for the first time,
like at boot/application startup.
Also the SELinux AVC is based on lists. It uses an object cache, but it
is still something that grows and is on the critical path of evaluating
the callbacks from the LSM hooks. A lot of them.
These are the main two reasons, so far, for me advocating an
optimization of the write-rare version of the (h)list.
--
igor
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
