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! -- 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/
