Received: by 10.223.176.46 with SMTP id f43csp405654wra; Thu, 18 Jan 2018 19:30:30 -0800 (PST) X-Google-Smtp-Source: ACJfBovh0XLE72rrux7c1QTxwfmJqScIQNzMZu2rr9BFUkp5J+UDaTWzbEAYqFdbPn22LjSJdYLz X-Received: by 10.99.97.137 with SMTP id v131mr34779134pgb.243.1516332630600; Thu, 18 Jan 2018 19:30:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516332630; cv=none; d=google.com; s=arc-20160816; b=N0XudDtLIoo6C8XtNJ+xsJWfMZVKEWl1UvxUBdQqshWPXIy/05tw9AL+4PifhUUJR2 r2NUREt9GFTE6MvEabOupHKKj6U3rM3KsNPHuiCiZdZRMvKTLlC5dK69efoMsAYAki+Z o/+PgwukGP3VWRHtJZzpW70mA0M8WKSSMa+fLVf7iVPptK0XANM4ojdoNwsvCCVBg7Mv lIIbb680cjEC53FvhktWdGhk+6OsYTQDQNO72duJU2FnHIMX9bL5/uAeAhk6MY5IefFI 4e7O5SEK5swGlOBhd5SPbWoCMQLaK/JXsRpUrjChqIgHNJZLYKrecOjnf4fYx6lAEJV8 Pvrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=wEVqm+SzARu0wiwyw5bdNaHgdJ8nAvqQJuOjKp/Roq4=; b=TsOOjRsA4BS3RT8FEL+HpTwu6VHfW0typRhOJa7P3y9xVbyfnvZL3QNqN8fJNcu/Dl +Qz8YH1IjSwqMVmlLytdWTjYQoP2EoQoJFga2L/Np2MQ50+R+vxx5swKHZ7rFIWxjXu8 CzGnFPuh3h7SNCfcDlHrmfdUhn/EMy4MFQRAuedZRKrWHxEDFkzLz4fVt6WZbOYHTKdK j46izyL82xTXhH3TcKK2IAsNDjlcdW7lBXtNhApA+8GX3M2HpfTFmB6rAnWVGXn4mqxY oUzIz3afjkzhxEJvEucO1t82z9xASdbehieL+6kXma3UJ8O1oe42jGBgU54bP8SmlR+4 CeNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c64si7492323pga.513.2018.01.18.19.30.16; Thu, 18 Jan 2018 19:30:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932567AbeASD2G convert rfc822-to-8bit (ORCPT + 99 others); Thu, 18 Jan 2018 22:28:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:36456 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932463AbeASD16 (ORCPT ); Thu, 18 Jan 2018 22:27:58 -0500 Received: from vmware.local.home (cpe-172-100-180-131.stny.res.rr.com [172.100.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7EFF72175B; Fri, 19 Jan 2018 03:27:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EFF72175B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Thu, 18 Jan 2018 22:27:53 -0500 From: Steven Rostedt To: Byungchul Park Cc: Petr Mladek , Sergey Senozhatsky , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Sergey Senozhatsky , Tejun Heo , Pavel Machek , linux-kernel@vger.kernel.org, kernel-team@lge.com Subject: Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes Message-ID: <20180118222753.3e3932be@vmware.local.home> In-Reply-To: <45bc7a00-2f7f-3319-bfed-e7b9cd7a8571@lge.com> References: <20180110132418.7080-1-pmladek@suse.com> <20180110132418.7080-2-pmladek@suse.com> <20180117120446.44ewafav7epaibde@pathway.suse.cz> <4a24ce1d-a606-3add-ec30-91ce9a1a1281@lge.com> <20180117211953.2403d189@vmware.local.home> <171cf5b9-2cb6-8e70-87f5-44ace35c2ce4@lge.com> <20180118102139.43c04de5@gandalf.local.home> <45bc7a00-2f7f-3319-bfed-e7b9cd7a8571@lge.com> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Jan 2018 11:37:13 +0900 Byungchul Park wrote: > On 1/19/2018 12:21 AM, Steven Rostedt wrote: > > On Thu, 18 Jan 2018 13:01:46 +0900 > > Byungchul Park wrote: > > > >>> I disagree. It is like a spinlock. You can say a spinlock() that is > >>> blocked is also waiting for an event. That event being the owner does a > >>> spin_unlock(). > >> > >> That's exactly what I was saying. Excuse me but, I don't understand > >> what you want to say. Could you explain more? What do you disagree? > > > > I guess I'm confused at what you are asking for then. > > Sorry for not enough explanation. What I asked you for is: > > 1. Relocate acquire()s/release()s. > 2. So make it simpler and remove unnecessary one. > 3. So make it look like the following form, > because it's a thing simulating "wait and event". > > A context > --------- > lock_map_acquire(wait); /* Or lock_map_acquire_read(wait) */ > /* "Read" one is better though.. */ why? I'm assuming you are talking about adding this to the current owner off the console_owner? This is a mutually exclusive section, no parallel access. Why the Read? > > /* A section, we suspect a wait for an event might happen. */ > ... > > lock_map_release(wait); > > The place actually doing the wait > --------------------------------- > lock_map_acquire(wait); > lock_map_release(wait); > > wait_for_event(wait); /* Actually do the wait */ > > Honestly, you used acquire()s/release()s as if they are cross- > release stuff which mainly handles general waits and events, > not only things doing "acquire -> critical area -> release". > But that's not in the mainline at the moment. Maybe it is more like that. Because, the thing I'm doing is passing off a semaphore ownership to the waiter. From a previous email: > > + if (spin) { > > + /* We spin waiting for the owner to release us */ > > + spin_acquire(&console_owner_dep_map, 0, 0, _THIS_IP_); > > + /* Owner will clear console_waiter on hand off */ > > + while (READ_ONCE(console_waiter)) > > + cpu_relax(); > > + > > + spin_release(&console_owner_dep_map, 1, _THIS_IP_); > > Why don't you move this over "while (READ_ONCE(console_waiter))" and > right after acquire()? > > As I said last time, only acquisitions between acquire() and release() > are meaningful. Are you taking care of acquisitions within cpu_relax()? > If so, leave it. There is no acquisitions between acquire and release. To get to "if (spin)" the acquire had to already been done. If it was released, this spinner is now the new "owner". There's no race with anyone else. But it doesn't technically have it till console_waiter is set to NULL. Why would we call release() before that? Or maybe I'm missing something. Or are you just saying that it doesn't matter if it is before or after the while() loop, to just put it before? Does it really matter? -- Steve