From: Davidlohr Bueso <dave@stgolabs.net>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH -next] mm/vmacache: inline vmacache_valid_mm()
Date: Thu, 8 Oct 2015 09:55:39 -0700 [thread overview]
Message-ID: <20151008165539.GA2594@linux-uzut.site> (raw)
In-Reply-To: <20151008134358.GA601@swordfish>
On Thu, 08 Oct 2015, Sergey Senozhatsky wrote:
>> >+/*
>> >+ * 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.
Thinking a bit more about it, we don't want to be making vmacache_valid_mm()
visible, as users should only stick to vmacache_valid() calls. I doubt that
this would infact ever occur, but it's a bad idea regardless.
So I'd rather keep my patch as is. Yes, the compiler can already inline it for
us, but making it explicit is certainly won't harm.
Thanks,
Davidlohr
next prev parent reply other threads:[~2015-10-08 16:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-08 4:17 [PATCH -next] mm/vmacache: inline vmacache_valid_mm() Davidlohr Bueso
2015-10-08 6:21 ` Sergey Senozhatsky
2015-10-08 13:23 ` Davidlohr Bueso
2015-10-08 13:43 ` Sergey Senozhatsky
2015-10-08 16:55 ` Davidlohr Bueso [this message]
2015-10-08 17:32 ` Davidlohr Bueso
2015-10-08 22:15 ` Andrew Morton
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=20151008165539.GA2594@linux-uzut.site \
--to=dave@stgolabs.net \
--cc=akpm@linux-foundation.org \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).