From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758327AbcBXUU7 (ORCPT ); Wed, 24 Feb 2016 15:20:59 -0500 Received: from terminus.zytor.com ([198.137.202.10]:46832 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753607AbcBXUU5 (ORCPT ); Wed, 24 Feb 2016 15:20:57 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <1452699925.6549.1456286963485.JavaMail.zimbra@efficios.com> 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-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH v4 0/5] getcpu_cache system call for 4.6 From: "H. Peter Anvin" Date: Wed, 24 Feb 2016 12:07:28 -0800 To: Mathieu Desnoyers CC: Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.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 Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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@zytor.com 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.