linux-kernel - Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

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: <CA+55aFzw-Yn6vOB1BvdoxH3tid14=uS1u3bgFWdtbAuO4r-zCQ@mail.gmail.com>
Date:	Wed, 10 Jun 2015 10:31:01 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Dave Hansen <dave.hansen@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Minchan Kim <minchan@...nel.org>,
	H Peter Anvin <hpa@...or.com>, Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 10:24 AM, Mel Gorman <mgorman@...e.de> wrote:
>
> Yes, that was done earlier today based on Ingo's review so that the
> allocation could be dealt with as a separate path at the end of the series.

Ahh, ok, never mind then.

> Ok, good point.  Patch 3 in my git tree ("mm: Dynamically allocate TLB
> batch unmap control structure") does not do this but I'll look into doing
> it before the release based on 4.2-rc1.

I'm not sure how size-sensitive this is. The 'struct task_struct' is
pretty big already, and if somebody builds a MAXSMP kernel, I really
don't think they worry too much about wasting a few bytes for each
process. Clearly they either are insane, or they actually *have* a big
machine, in which point the allocation is not going to be wasteful and
they'll likely trigger this code all the time anyway, so trying to be
any more dynamic about it is probably not worth it.

So my "maybe you could use 'cpumask_var_t' here" suggestion isn't
necessarily even worth it. Just statically allocating it is probably
perfectly fine.

Of course, again the counter-example for that may well be how distros
seem to make thousand-cpu configurations the default. That does seem
insane to me. But I guess the pain of multiple kernel configs is just
too much.

                Linus
--
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/