From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH v4 0/5] getcpu_cache system call for 4.6 Date: Wed, 24 Feb 2016 12:07:28 -0800 Message-ID: References: <1456270120-7560-1-git-send-email-mathieu.desnoyers@efficios.com> <56CD091A.4060009@zytor.com> <1452699925.6549.1456286963485.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1452699925.6549.1456286963485.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mathieu Desnoyers Cc: Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api , Paul Turner , Andrew Hunter , Peter Zijlstra , Andy Lutomirski , Andi Kleen , Dave Watson , Chris Lameter , Ben Maurer , rostedt , "Paul E. McKenney" , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk List-Id: linux-api@vger.kernel.org On February 23, 2016 8:09:23 PM PST, Mathieu Desnoyers wrote: >----- On Feb 23, 2016, at 8:36 PM, H. Peter Anvin hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org wrote: > >> On 02/23/2016 03:28 PM, Mathieu Desnoyers wrote: >>> Hi, >>> >>> Here is a patchset implementing a cache for the CPU number of the >>> currently running thread in user-space. >>> >>> Benchmarks comparing this approach to a getcpu based on system call >on >>> ARM show a 44x speedup. They show a 14x speedup on x86-64 compared >to >>> executing lsl from a vDSO through glibc. >>> >>> I'm added a man page in the changelog of patch 1/3, which shows an >>> example usage of this new system call. >>> >>> This series is based on v4.5-rc5, submitted for Linux 4.6. >>> >>> Feedback is welcome, >>> >> >> What is the resulting context switch overhead? > >The getcpu_cache only adds code to the thread migration path, >and to the resume notifier. The context switch path per se is >untouched. I would therefore expect the overhead on context >switch to be within the noise, except if stuff like hackbench >would be so sensitive to the size of struct task_struct that >a single extra pointer added at the end of struct task_struct >would throw off the benchmarks. > >Is that what you are concerned about ? > >Thanks, > >Mathieu Yes, I'd like to see numbers. It is way easy to handwave small changes away, but they add up over time. Without numbers it is a bit hard to quantify the pro vs con. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.