From: Josh Triplett <josh@joshtriplett.org>
To: "Seymour, Shane M" <shane.seymour@hpe.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Thomas Gleixner <tglx@linutronix.de>,
Paul Turner <pjt@google.com>, Andrew Hunter <ahh@google.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Andi Kleen <andi@firstfloor.org>,
Dave Watson <davejwatson@fb.com>, Chris Lameter <cl@linux.com>,
Ingo Molnar <mingo@redhat.com>, Ben Maurer <bmaurer@fb.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Russell King <linux@arm.linux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [RFC PATCH 0/3] Implement getcpu_cache system call
Date: Mon, 11 Jan 2016 15:03:06 -0800 [thread overview]
Message-ID: <20160111230306.GC28717@cloud> (raw)
In-Reply-To: <DDB9C85B850785449757F9914A034FCB4450ACF7@G9W0766.americas.hpqcorp.net>
On Mon, Jan 11, 2016 at 10:38:28PM +0000, Seymour, Shane M wrote:
> I have some concerns and suggestions for you about this.
>
> What's to stop someone in user space from requesting an arbitrarily large number of CPU # cache locations that the kernel needs to allocate memory to track and each time the task migrates to a new CPU it needs to update them all? Could you use it to dramatically slow down a system/task switching? Should there be a ulimit type value or a sysctl setting to limit the number that you're allowed to register per-task?
The documented behavior of the syscall allows only one location per
thread, so the kernel can track that one and only address rather easily
in the task_struct. Allowing dynamic allocation definitely doesn't seem
like a good idea.
- Josh Triplett
next prev parent reply other threads:[~2016-01-11 23:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 7:01 [RFC PATCH 0/3] Implement getcpu_cache system call Mathieu Desnoyers
2016-01-05 7:01 ` [RFC PATCH 2/3] getcpu_cache: wire up ARM " Mathieu Desnoyers
[not found] ` <1451977320-4886-1-git-send-email-mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2016-01-05 7:01 ` [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers
2016-01-05 12:04 ` Will Deacon
2016-01-05 17:31 ` Mathieu Desnoyers
[not found] ` <1079064730.338115.1452015105259.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2016-01-05 17:34 ` Mathieu Desnoyers
2016-01-05 17:40 ` Russell King - ARM Linux
2016-01-05 17:49 ` Mathieu Desnoyers
[not found] ` <20160105174017.GY19062-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2016-01-05 21:47 ` Paul E. McKenney
[not found] ` <20160105214717.GE3818-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-01-05 22:34 ` Mathieu Desnoyers
[not found] ` <1777488643.338535.1452033244991.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2016-01-05 22:54 ` Paul E. McKenney
2016-01-05 7:02 ` [RFC PATCH 3/3] getcpu_cache: wire up x86 32/64 system call Mathieu Desnoyers
2016-01-11 22:38 ` [RFC PATCH 0/3] Implement getcpu_cache " Seymour, Shane M
2016-01-11 23:03 ` Josh Triplett [this message]
2016-01-12 0:49 ` Mathieu Desnoyers
2016-01-12 2:45 ` Josh Triplett
2016-01-12 4:27 ` Ben Maurer
2016-01-12 6:40 ` Seymour, Shane M
[not found] ` <9F8D25C2-B5EE-479D-BD61-0FE466962B9E-b10kYP2dOMg@public.gmane.org>
2016-01-12 13:15 ` Mathieu Desnoyers
[not found] ` <467525713.343916.1452604549209.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2016-01-12 21:02 ` Ben Maurer
[not found] ` <5CDDBDF2D36D9F43B9F5E99003F6A0D49A1426A5-f8hGUhss0nh9TZdEUguypQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2016-01-13 0:22 ` Mathieu Desnoyers
[not found] ` <484967406.344576.1452644549992.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2016-01-13 0:51 ` Josh Triplett
[not found] ` <33D8C4C1-472E-4C3E-B722-B890FD592E23-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
2016-01-14 15:58 ` Mathieu Desnoyers
[not found] ` <DDB9C85B850785449757F9914A034FCB4450ACF7-4I1V4pQFGigSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
2016-01-11 23:16 ` Seymour, Shane M
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=20160111230306.GC28717@cloud \
--to=josh@joshtriplett.org \
--cc=ahh@google.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=bmaurer@fb.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=davejwatson@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=luto@amacapital.net \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rostedt@goodmis.org \
--cc=shane.seymour@hpe.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.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).