From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Triplett Subject: Re: [RFC PATCH 0/3] Implement getcpu_cache system call Date: Mon, 11 Jan 2016 15:03:06 -0800 Message-ID: <20160111230306.GC28717@cloud> References: <1451977320-4886-1-git-send-email-mathieu.desnoyers@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Seymour, Shane M" Cc: Mathieu Desnoyers , Thomas Gleixner , Paul Turner , Andrew Hunter , Peter Zijlstra , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , Andy Lutomirski , Andi Kleen , Dave Watson , Chris Lameter , Ingo Molnar , Ben Maurer , Steven Rostedt , "Paul E. McKenney" , Linus Torvalds , Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Michael Kerrisk List-Id: linux-api@vger.kernel.org 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