From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932842AbbI3U2r (ORCPT ); Wed, 30 Sep 2015 16:28:47 -0400 Received: from nat13.teradata.com ([153.65.16.13]:23526 "EHLO rpc7292.td.teradata.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932502AbbI3U2n convert rfc822-to-8bit (ORCPT ); Wed, 30 Sep 2015 16:28:43 -0400 From: "Meyer, Mike" To: Peter Zijlstra CC: "linux-kernel@vger.kernel.org" , "mingo@redhat.com" Subject: RE: [PATCH] sched: fix task and run queue run_delay inconsistencies Thread-Topic: [PATCH] sched: fix task and run queue run_delay inconsistencies Thread-Index: AQHQ+5ec4vHMVXsrQkmW7etVQ6osjJ5VReIQ Date: Wed, 30 Sep 2015 20:28:41 +0000 Message-ID: <72105DE171429F468B83CE64C279BFFA17615A68@SUSHDC8002.TD.TERADATA.COM> References: <72105DE171429F468B83CE64C279BFFA1760DC12@SUSHDC8002.TD.TERADATA.COM> <20150930154413.GO3604@twins.programming.kicks-ass.net> In-Reply-To: <20150930154413.GO3604@twins.programming.kicks-ass.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.64.133.129] X-TM-AS-Product-Ver: IMSVA-8.5.0.1618-8.0.0.1202-21850.002 X-TM-AS-Result: No--18.517-7.0-31-10 X-TM-AS-User-Approved-Sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-TM-AS-MML: disable X-imss-scan-details: No--18.517-7.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1618-8.0.1202-21850.002 X-TMASE-Result: 10--18.516600-5.000000 X-TMASE-MatchedRID: VfovoVrt/oY4HKI/yaqRm5Y9D0/NRxoqcirjb9r+VbuKlJ71TX9+g6Sx VUPqsOdUiI8BR8X58b2lyH+LgJssgaezlDj0PvT9F6z9HGHKwNsIYICTzfK2gVuLVkUNPNw0RQO kMfXmc2fjVqMSw/CP2vc1CRxk5qwtXZXnjooQdcgZXJLztZviXONZPwab8qQdRL9uhZIYy1105f ixap3yFCIBcUJpYgcr9h8wXCBDPua13pYqQ8YOFmzBijri5+RVB0I+iCUO453I9BHsOEzeNhzll v0af4rK0LqCaNlK8HKkLSzpHNTR2hgHZ8655DOP/sToY2qzpx7dB/CxWTRRuyUIayx+Skid Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: Peter Zijlstra [mailto:peterz@infradead.org] > > On Wed, Sep 23, 2015 at 12:37:18AM +0000, Meyer, Mike wrote: > > > > The proposed patch addresses the issue by calling > > sched_info_reset_dequeued(thread) following the call to > > enqueue_task(rq, thread) for running threads in situations in which > > thread->sched_info.last_queued should remain 0. > > Would something like the below; which avoids calling > sched_info_{de,}queued() for these sites also work? > > It even shrinks the code (due to inlining {en,de}queue_task()): > > $ size defconfig-build/kernel/sched/core.o defconfig- > build/kernel/sched/core.o.orig > text data bss dec hex filename > 64019 23378 2344 89741 15e8d defconfig-build/kernel/sched/core.o > 64149 23378 2344 89871 15f0f defconfig-build/kernel/sched/core.o.orig > Yes that will also address the issue. The reason I approached the way I did was to avoid adding code path to the far more common uses of {en,de}queue_task() but I doubt anyone is going to notice a difference with the addition of some register save/restores and a compare in that path. Overall the code does shrink with the alternative which is good. My only comment is I am not sure about the naming of the flag ENQUEUE_TEMP which implies (to me) the enqueue is temporary which clearly it isn't. Maybe something like DEQUEUE_MOVE/ENQUEUE_MOVE would be a bit more descriptive of the use case. Other than that I am fine with what you proposed. Thanks!