On Tue 2020-08-11 11:29:24, Paul Menzel wrote:
> Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the
> last time, the the default log buffer size bump was increased.
>
> Machines have evolved, and on current hardware, enough memory is
> present, and some devices have over 200 PCI devices, like a two socket
> Skylake-E server, resulting a lot of lines.
>
> Therefore, increase the default from 128 KB to 512 KB. Anyone, with
> limited memory, can still lower it.
>
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -681,9 +681,9 @@ config IKHEADERS
> kheaders.ko is built which can be loaded on-demand to get access to headers.
>
> config LOG_BUF_SHIFT
> - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
> + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)"
> range 12 25
> - default 17
> + default 19
> depends on PRINTK
> help
> Select the minimal kernel log buffer size as a power of 2.
Honestly, I do not have experience with changing the defaults. People
hacking small devices might complain. Well, this can be solved
by increasing the default only when BASE_FULL is set.
I am personally fine with increasing the default when BASE_FULL
is set. The amount of messages is growing over time because of
increasing complexity of both the hardware and software.
Fortunately also the amount of available memory is growing.
Well, this should get discussed in wider audience. Adding some
people into CC.
JFYI, it started with report of lost messages, see
https://lore.kernel.org/lkml/[email protected]/
Best Regards,
Petr
Dear Petr,
Am 11.08.20 um 12:53 schrieb Petr Mladek:
> On Tue 2020-08-11 11:29:24, Paul Menzel wrote:
>> Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the
>> last time, the the default log buffer size bump was increased.
>>
>> Machines have evolved, and on current hardware, enough memory is
>> present, and some devices have over 200 PCI devices, like a two socket
>> Skylake-E server, resulting a lot of lines.
>>
>> Therefore, increase the default from 128 KB to 512 KB. Anyone, with
>> limited memory, can still lower it.
>>
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -681,9 +681,9 @@ config IKHEADERS
>> kheaders.ko is built which can be loaded on-demand to get access to headers.
>>
>> config LOG_BUF_SHIFT
>> - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
>> + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)"
>> range 12 25
>> - default 17
>> + default 19
>> depends on PRINTK
>> help
>> Select the minimal kernel log buffer size as a power of 2.
>
> Honestly, I do not have experience with changing the defaults. People
> hacking small devices might complain. Well, this can be solved
> by increasing the default only when BASE_FULL is set.
>
> I am personally fine with increasing the default when BASE_FULL
> is set. The amount of messages is growing over time because of
> increasing complexity of both the hardware and software.
> Fortunately also the amount of available memory is growing.
>
> Well, this should get discussed in wider audience. Adding some
> people into CC.
>
> JFYI, it started with report of lost messages, see
> https://lore.kernel.org/lkml/[email protected]/
As there was no objection, is it possible to apply the two patches, and
maybe even get them into Linux 5.10?
Kind regards,
Paul
On Thu 2020-10-29 23:16:01, Paul Menzel wrote:
> Dear Petr,
>
>
> Am 11.08.20 um 12:53 schrieb Petr Mladek:
> > On Tue 2020-08-11 11:29:24, Paul Menzel wrote:
> > > Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the
> > > last time, the the default log buffer size bump was increased.
> > >
> > > Machines have evolved, and on current hardware, enough memory is
> > > present, and some devices have over 200 PCI devices, like a two socket
> > > Skylake-E server, resulting a lot of lines.
> > >
> > > Therefore, increase the default from 128 KB to 512 KB. Anyone, with
> > > limited memory, can still lower it.
> > >
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -681,9 +681,9 @@ config IKHEADERS
> > > kheaders.ko is built which can be loaded on-demand to get access to headers.
> > > config LOG_BUF_SHIFT
> > > - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
> > > + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)"
> > > range 12 25
> > > - default 17
> > > + default 19
> > > depends on PRINTK
> > > help
> > > Select the minimal kernel log buffer size as a power of 2.
> >
> > Honestly, I do not have experience with changing the defaults. People
> > hacking small devices might complain. Well, this can be solved
> > by increasing the default only when BASE_FULL is set.
> >
> > I am personally fine with increasing the default when BASE_FULL
> > is set. The amount of messages is growing over time because of
> > increasing complexity of both the hardware and software.
> > Fortunately also the amount of available memory is growing.
> >
> > Well, this should get discussed in wider audience. Adding some
> > people into CC.
> >
> > JFYI, it started with report of lost messages, see
> > https://lore.kernel.org/lkml/[email protected]/
>
> As there was no objection, is it possible to apply the two patches, and
> maybe even get them into Linux 5.10?
Thanks for reminding me. I am sorry but it is too late for
5.10. Such a change should be added during the merge window.
Well, the size of the ring buffer has effectively increased in 5.10.
The lockless implementation stores strings and metadata separately.
It basically doubled the memory needs and people around embedded
devices were not happy, see
https://lore.kernel.org/r/CAMuHMdXHFFUrjRMEHnXXU8QQkgD9x_S6R3N0Q7Q4H2RSfy2GGw@mail.gmail.com
Please update the patch so that the default stays the same for
BASE_SMALL. Please, add Rasmus Villemoes
<[email protected]> and Geert Uytterhoeven
<[email protected]> into CC when you send it.
Best Regards,
Petr