Messages in this thread | | | Subject | Re: Logging More Messages? | Date | Fri, 10 May 1996 11:02:57 -0500 (CDT) | From | (Mike Castle) |
| |
Amazingly enough lilo said: > > Actually, it's an internal buffer. See kernel/printk.c. It's > > 8k. > > Sort of a semantic point.
True. But that explains why messages that could be seen on the scroll back weren't being written to the logs. They over flowed the internal buffer, but not the memory associated with the screen.
> > If you're generating more than 8k of data, perhaps you can > > rearrange things to start up syslog sooner. > > Or the buffer could be extended. 8k isn't much, this might make a nice > config option if it isn't already.
About the only time a buffer this large is useful is upon boot. After boot, I doubt the buffer ever fills up if the sysklogd stuff is running. A larger buffer just for catching all the boot messages might not be the best solution.
This reminds me. There was once a page that had a bunch of patches for improving kernel memory usage. It include such things as kswap (before it became official), reducing the number of supported options for floppy drives (ie, only using 1.44 and 720 for a 3.5, for example, not all the other esoteric ones), and reducing said buffer to 1k.
For a stable system, mebbe not a bad idea. For a system with modifications (ie, new hardware, new kernel, etc), perhaps upping the buffer to be sure to catch everything isn't a bad thing. Shame that buffer can't be kmalloced (It could be called by kmalloc).
mrc -- Mike Castle .-=NEXUS=-. Life is like a clock: You can work constantly mcastle@cs.umr.edu and be right all the time, or not work at all mcastle@umr.edu and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen
| |