From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752629AbdEPKcq (ORCPT ); Tue, 16 May 2017 06:32:46 -0400 Received: from foss.arm.com ([217.140.101.70]:34280 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbdEPKcp (ORCPT ); Tue, 16 May 2017 06:32:45 -0400 Date: Tue, 16 May 2017 11:32:41 +0100 From: Juri Lelli To: Byungchul Park Cc: Steven Rostedt , peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, juri.lelli@gmail.com, bristot@redhat.com, kernel-team@lge.com Subject: Re: [PATCH v4 1/5] sched/deadline: Refer to cpudl.elements atomically Message-ID: <20170516103241.xony5rtmqi66gczy@e106622-lin> References: <1494568129-9985-1-git-send-email-byungchul.park@lge.com> <1494568129-9985-2-git-send-email-byungchul.park@lge.com> <20170512102530.50b85979@gandalf.local.home> <20170516065223.GA24127@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170516065223.GA24127@X58A-UD3R> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/05/17 15:52, Byungchul Park wrote: > On Fri, May 12, 2017 at 10:25:30AM -0400, Steven Rostedt wrote: > > On Fri, 12 May 2017 14:48:45 +0900 > > Byungchul Park wrote: > > > > > cpudl.elements is an instance that should be protected with a spin lock. > > > Without it, the code would be insane. > > > > And how much contention will this add? Spin locks in the scheduler code > > that are shared among a domain can cause huge latency. This was why I > > worked hard not to add any in the cpupri code. > > Yes. That's also whay I hesitated to post this patch.. > > > > Current cpudl_find() has problems like, > > > > > > 1. cpudl.elements[0].cpu might not match with cpudl.elements[0].dl. > > > 2. cpudl.elements[0].dl(u64) might not be referred atomically. > > > 3. Two cpudl_maximum()s might return different values. > > > 4. It's just insane. > > > > And lockless algorithms usually are insane. But locks come with a huge > > cost. What happens when we have 32 core domains. This can cause > > tremendous contention and makes the entire cpu priority for deadlines > > useless. Might as well rip out the code. > > I think it would be better if we, even keeping it lockless, > > 1. make cp->elements[].cpu referred once than twice, > 2. add retry logic in order to match elements[].cpu with its dl, > 3. add retry logic for the u64 variable to be read atomically, > > So what do you think about the suggestions? Of course it does not solve > the problems perfectly though.. Or do you think it's not worth? > Not sure, but if we are going to retry a lot it might be better off to put proper locking instead? We could also simply bail out when we notice that something is changed under our feet. I'd say (again :) we might first want to understand (with some numbers) how bad the problem is and then fix it. I guess numbers might also help us to better understand what the best fix is? Thanks, - Juri