From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751968AbaFZXQg (ORCPT ); Thu, 26 Jun 2014 19:16:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45219 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312AbaFZXQf (ORCPT ); Thu, 26 Jun 2014 19:16:35 -0400 Date: Fri, 27 Jun 2014 01:16:30 +0200 From: "Luis R. Rodriguez" To: Andrew Morton Cc: "Luis R. Rodriguez" , gregkh@linuxfoundation.org, hpa@linux.intel.com, linux-kernel@vger.kernel.org, Andrew Lunn , Stephen Warren , Michal Hocko , Petr Mladek , Joe Perches , Arun KS , Kees Cook , Davidlohr Bueso , Chris Metcalf Subject: Re: [PATCH v8 4/4] printk: allow increasing the ring buffer depending on the number of CPUs Message-ID: <20140626231630.GI27687@wotan.suse.de> References: <1403124337-14886-1-git-send-email-mcgrof@do-not-panic.com> <1403124337-14886-4-git-send-email-mcgrof@do-not-panic.com> <20140623154134.43ac7ab63896cd9ebcba84b6@linux-foundation.org> <20140624002050.GC27687@wotan.suse.de> <20140623174533.88663e64.akpm@linux-foundation.org> <20140624010554.GF27687@wotan.suse.de> <20140626144117.3412feee6234786be098259d@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140626144117.3412feee6234786be098259d@linux-foundation.org> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 26, 2014 at 02:41:17PM -0700, Andrew Morton wrote: > On Tue, 24 Jun 2014 03:05:54 +0200 "Luis R. Rodriguez" wrote: > > > > > Ah, because its cpu_extra, not total_cpu_space that is being > > > > computed, the goal was to see how much extra junk on the > > > > worst case a CPU might contribute. The __LOG_BUF_LEN is the > > > > default size, so we combine both. > > > > > > Well... why? Isn't it simpler and more direct to say "I want at least > > > 32k per CPU"? > > > > That's certainly another way to go about this, but the original motivation > > was trying to figure out the additional *extra* junk a CPU might spewed out, > > it set out with an assumption of a base start from the first CPU booting the > > system and that first CPU using the default kernel ring buffer size. The > > language in the patch describes the worst case extra CPU junk contributed, > > rather than a specific full split of the kernel ring buffer as that's typically > > how extra junk is spewered out to the ring bufer and the concern. In general > > on idle each CPU only contributes about only 1 to max 2 lines. The focus then > > is the worst case on contribution. > > I don't think I understood all that ;) Yeah if that made *you* squint a simpler approach would be better, regardless of how technically correct the above explanation may be. > > Another note -- since this option depends on SMP and !BASE_SMALL technically > > num_possible_cpus() won't ever return something smaller than or equal to 1 > > but because of the default values chosen the -1 on the compuation does affect > > whether or not this will trigger on > 64 CPUs or >= 64 CPUs, keeping the > > -1 means we require > 64 CPUs. > > hm, that sounds like more complexity. > > > This all can be changed however we like but the language and explained logic > > would just need to be changed. > > Let's start out simple. What's wrong with doing > > log buf len = max(__LOG_BUF_LEN, nr_possible_cpus * per-cpu log buf len) Sure, you already took in the patch series though so how would you like to handle a respin, you just drop the last patch and we respin it? Luis