Messages in this thread | | | Date | Fri, 27 Jun 2014 01:16:30 +0200 | From | "Luis R. Rodriguez" <> | Subject | Re: [PATCH v8 4/4] printk: allow increasing the ring buffer depending on the number of CPUs |
| |
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" <mcgrof@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
| |