From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965869AbcAZNaG (ORCPT ); Tue, 26 Jan 2016 08:30:06 -0500 Received: from mga01.intel.com ([192.55.52.88]:15054 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964910AbcAZNaC (ORCPT ); Tue, 26 Jan 2016 08:30:02 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,350,1449561600"; d="scan'208";a="901378026" Subject: Re: [RFC][PATCH v2] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread. To: John Stultz , lkml References: <1453782484-3887-1-git-send-email-john.stultz@linaro.org> Cc: Ruchi Kandoi , Thomas Gleixner , Oren Laadan , Micha Kalfon , Rom Lemarchand , Android Kernel Team From: Arjan van de Ven Message-ID: <56A774D8.5020401@linux.intel.com> Date: Tue, 26 Jan 2016 05:30:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1453782484-3887-1-git-send-email-john.stultz@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/25/2016 8:28 PM, John Stultz wrote: > From: Ruchi Kandoi > > This allows power/performance management software to set timer > slack for other threads according to its policy for the thread > (such as when the thread is designated foreground vs. background > activity) > > Second argument is similar to PR_SET_TIMERSLACK, if non-zero > then the slack is set to that value otherwise sets it to the > default for the thread. > > Takes PID of the thread as the third argument. > > This interface checks that the calling task has permissions to > to use PTRACE_MODE_ATTACH on the target task, so that we can > ensure arbitrary apps do not change the timer slack for other > apps. Acked-by: Arjan van de Ven only slight concern is the locking around the value of the field in the task struct, but nobody does read-modify-write on it, so they'll get either the new or the old version, which should be ok. (until now only the local thread would touch the field, and if you're setting it, by definition you're not going to sleep yet, so you're not using the field)