Re: [PATCH v8 4/4] printk: allow increasing the ring buffer depending on the number of CPUs

[Luis R. Rodriguez]

On Thu, Jun 26, 2014 at 4:20 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 27 Jun 2014 01:16:30 +0200 "Luis R. Rodriguez" <mcgrof@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/