From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762031AbcALAtp (ORCPT ); Mon, 11 Jan 2016 19:49:45 -0500 Received: from mail.efficios.com ([78.47.125.74]:45871 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761503AbcALAtn (ORCPT ); Mon, 11 Jan 2016 19:49:43 -0500 Date: Tue, 12 Jan 2016 00:49:18 +0000 (UTC) From: Mathieu Desnoyers To: Josh Triplett Cc: Shane M Seymour , Thomas Gleixner , Paul Turner , Andrew Hunter , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-api , Andy Lutomirski , Andi Kleen , Dave Watson , Chris Lameter , Ingo Molnar , Ben Maurer , rostedt , "Paul E. McKenney" , Linus Torvalds , Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Michael Kerrisk Message-ID: <137700396.343696.1452559758752.JavaMail.zimbra@efficios.com> In-Reply-To: <20160111230306.GC28717@cloud> References: <1451977320-4886-1-git-send-email-mathieu.desnoyers@efficios.com> <20160111230306.GC28717@cloud> Subject: Re: [RFC PATCH 0/3] Implement getcpu_cache system call MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF43 (Linux)/8.6.0_GA_1178) Thread-Topic: Implement getcpu_cache system call Thread-Index: Rmo4L6V3zfWQkDQFcrlN9joaMF1tUw== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jan 11, 2016, at 6:03 PM, Josh Triplett josh@joshtriplett.org wrote: > 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. The current implementation now allows more than one location per thread. Which piece of documentation states that only one location per thread is allowed ? This was indeed the case for the prior implementations, but I moved to implementing a linked-list of cpu_cache areas per thread to allow the getcpu_cache system call to be used by more than a single shared object within a given program. Without the linked list, as soon as more than one shared object try to register their cache, the first one will prohibit all others from doing so. We could perhaps try to document that this system call should only ever be used by *libc, and all libraries and applications should then use the libc TLS cache variable, but it seems rather fragile, and any app/lib could try to register its own cache. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [RFC PATCH 0/3] Implement getcpu_cache system call Date: Tue, 12 Jan 2016 00:49:18 +0000 (UTC) Message-ID: <137700396.343696.1452559758752.JavaMail.zimbra@efficios.com> References: <1451977320-4886-1-git-send-email-mathieu.desnoyers@efficios.com> <20160111230306.GC28717@cloud> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160111230306.GC28717@cloud> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Josh Triplett Cc: Shane M Seymour , Thomas Gleixner , Paul Turner , Andrew Hunter , Peter Zijlstra , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api , Andy Lutomirski , Andi Kleen , Dave Watson , Chris Lameter , Ingo Molnar , Ben Maurer , rostedt , "Paul E. McKenney" , Linus Torvalds , Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Michael Kerrisk List-Id: linux-api@vger.kernel.org ----- On Jan 11, 2016, at 6:03 PM, Josh Triplett josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org wrote: > 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. The current implementation now allows more than one location per thread. Which piece of documentation states that only one location per thread is allowed ? This was indeed the case for the prior implementations, but I moved to implementing a linked-list of cpu_cache areas per thread to allow the getcpu_cache system call to be used by more than a single shared object within a given program. Without the linked list, as soon as more than one shared object try to register their cache, the first one will prohibit all others from doing so. We could perhaps try to document that this system call should only ever be used by *libc, and all libraries and applications should then use the libc TLS cache variable, but it seems rather fragile, and any app/lib could try to register its own cache. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com