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" <mcg...@suse.com> > 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 -- 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/