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: 42+ 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 ` Mathieu Desnoyers
2016-01-05 7:01 ` [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers
2016-01-05 7:01 ` Mathieu Desnoyers
2016-01-05 12:04 ` Will Deacon
2016-01-05 17:31 ` Mathieu Desnoyers
2016-01-05 17:34 ` Mathieu Desnoyers
2016-01-05 17:34 ` Mathieu Desnoyers
2016-01-05 17:40 ` Russell King - ARM Linux
2016-01-05 17:40 ` Russell King - ARM Linux
2016-01-05 17:49 ` Mathieu Desnoyers
2016-01-05 21:47 ` Paul E. McKenney
2016-01-05 21:47 ` Paul E. McKenney
2016-01-05 22:34 ` Mathieu Desnoyers
2016-01-05 22:34 ` Mathieu Desnoyers
2016-01-05 22:54 ` Paul E. McKenney
2016-01-05 22:54 ` Paul E. McKenney
2016-01-05 7:01 ` [RFC PATCH 2/3] getcpu_cache: wire up ARM system call Mathieu Desnoyers
2016-01-05 7:02 ` [RFC PATCH 3/3] getcpu_cache: wire up x86 32/64 " Mathieu Desnoyers
2016-01-05 7:02 ` Mathieu Desnoyers
2016-01-11 22:38 ` [RFC PATCH 0/3] Implement getcpu_cache " Seymour, Shane M
2016-01-11 22:38 ` Seymour, Shane M
2016-01-11 23:03 ` Josh Triplett [this message]
2016-01-12 0:49 ` Mathieu Desnoyers
2016-01-12 0:49 ` Mathieu Desnoyers
2016-01-12 2:45 ` Josh Triplett
2016-01-12 4:27 ` Ben Maurer
2016-01-12 4:27 ` Ben Maurer
2016-01-12 6:40 ` Seymour, Shane M
2016-01-12 6:40 ` Seymour, Shane M
2016-01-12 13:15 ` Mathieu Desnoyers
2016-01-12 13:15 ` Mathieu Desnoyers
2016-01-12 21:02 ` Ben Maurer
2016-01-12 21:02 ` Ben Maurer
2016-01-13 0:22 ` Mathieu Desnoyers
2016-01-13 0:22 ` Mathieu Desnoyers
2016-01-13 0:51 ` Josh Triplett
2016-01-13 0:51 ` Josh Triplett
2016-01-14 15:58 ` Mathieu Desnoyers
2016-01-14 15:58 ` Mathieu Desnoyers
2016-01-11 23:16 ` Seymour, Shane M
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.