On Thu, Jun 26, 2014 at 4:20 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Fri, 27 Jun 2014 01:16:30 +0200 "Luis R. Rodriguez" <mcg...@suse.com> > wrote: > >> > > 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? > > A fresh patch would suit. That's if you think it is a reasonable > approach - you've thought about this stuff more than I have!
The way its implemented now makes more technical sense, in short it assumes the first boot (and CPU) gets the full default kernel ring buffer size, the extra size is for the gibberish that each extra CPU is expected to spew out in the worst case. What you propose makes the explanation simpler and easier to understand but sends the wrong message about exactly how the growth of the kernel ring buffer is expected scale with the addition of more CPUs. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
