From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751308AbdBXNmK (ORCPT ); Fri, 24 Feb 2017 08:42:10 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:52780 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751125AbdBXNmB (ORCPT ); Fri, 24 Feb 2017 08:42:01 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 996B2607A2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=kimran@codeaurora.org To: linux-arm-kernel@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org From: Imran Khan Subject: Perf degradation seen with thread_info stored in sp_el0 Message-ID: <72e51627-9155-96f2-f7a9-1be8a8198930@codeaurora.org> Date: Fri, 24 Feb 2017 19:11:55 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I am observing some degradation in context switch performance (reported by sched benchmark of perf), after including the change to keep thread_info in sp_el0: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cdf9c7ca687e01840d0215437620a20263012fc However, if I use D0 to store the same information, I see that performance improves. For example, I am getting following numbers for the above mentioned scenarios: Thread info obtained from stack: /data/local # ./perf bench sched messaging -g 5 -l 500 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 5 groups == 200 processes run Total time: 2.911 [sec] Thread info obtained from sp_el0: /data/local # ./perf bench sched messaging -g 5 -l 500 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 5 groups == 200 processes run Total time: 3.590 [sec] Thread info obtained from D0: /data/local # ./perf bench sched messaging -g 5 -l 500 # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 5 groups == 200 processes run Total time: 3.103 [sec] So keeping thread_info in sp_el0 is resulting in degradation of around 23% , while keeping the same in D0 is resulting in degradation of about 6-7%. Of course so far my test cases are not involving cases where D0 might get changed in kernel space itself e.g. snippets under kernel_neon_begin/end and taking care of those cases will have further overhead. But right now I just wanted to have a feedback regarding, what are the possible complications I may face if I try to keep thread_info in D0 and whether such a solution will be feasible or not. Moreover is there any other alternative way to get rid of this performance degradation. Thanks and Regards, Imran -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation