linux-kernel - Re: [PATCH -next] mm/vmacache: inline vmacache_valid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151008134358.GA601@swordfish>
Date:	Thu, 8 Oct 2015 22:43:58 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH -next] mm/vmacache: inline vmacache_valid_mm()

On (10/08/15 06:23), Davidlohr Bueso wrote:
> >After moving vmacache_update() and vmacache_valid_mm() to include/linux/vmacache.h
> >(both `static inline')
> >
> >
> >./scripts/bloat-o-meter vmlinux.o.old vmlinux.o
> >add/remove: 0/1 grow/shrink: 1/0 up/down: 22/-54 (-32)
> >function                                     old     new   delta
> >find_vma                                      97     119     +22
> >vmacache_update                               54       -     -54
> >
> >
> >Something like this, perhaps?
> 
> iirc we actually had something like this in its original form, and akpm was forced
> to move things around for all users to be happy and not break the build. But yeah,
> that vmacache_update() could certainly be inlined if we can have it so. It's no
> where near as hot a path as the mm validity check (we have a good hit rate), but still
> seems reasonable.

Hello,

Andrew "was forced to move things around", hm, I need to google for it.

Davidlohr, care to send a V2? (this is just a minor improvement to your
patch).

> >
> >---
> >
> >include/linux/vmacache.h | 21 ++++++++++++++++++++-
> >mm/vmacache.c            | 20 --------------------
> >2 files changed, 20 insertions(+), 21 deletions(-)
> >
> >diff --git a/include/linux/vmacache.h b/include/linux/vmacache.h
> >index c3fa0fd4..0ec750b 100644
> >--- a/include/linux/vmacache.h
> >+++ b/include/linux/vmacache.h
> >@@ -15,8 +15,27 @@ static inline void vmacache_flush(struct task_struct *tsk)
> >	memset(tsk->vmacache, 0, sizeof(tsk->vmacache));
> >}
> >
> >+/*
> >+ * This task may be accessing a foreign mm via (for example)
> >+ * get_user_pages()->find_vma().  The vmacache is task-local and this
> >+ * task's vmacache pertains to a different mm (ie, its own).  There is
> >+ * nothing we can do here.
> >+ *
> >+ * Also handle the case where a kernel thread has adopted this mm via use_mm().
> >+ * That kernel thread's vmacache is not applicable to this mm.
> >+ */
> >+static bool vmacache_valid_mm(struct mm_struct *mm)
> 
> This needs (explicit) inlined, no?
> 

oh, yeah. Funny how I said "both `static inline'" and made 'inline' only
one of them.

	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/