Kernel configuration options
John Richard Moser
nigelenki at comcast.net
Wed Jan 2 21:55:55 EST 2008
Albert Cahalan wrote:
> [various people]
>
>> BSD process accounting and auditd support though?
>
> BSD process accounting can be very useful for debugging.
> It is particularly valuable when you have programs being
> started from weird places, being debugged already, or
> crossing through stuff like setuid. It doesn't cost much.
>
> I suspect the auditd support may likewise prove useful.
>
>> CONFIG_PROFILING, CONFIG_KPROBES, CONFIG_DEBUG_FS,
>> CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS,
>> CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK
>
> We need CONFIG_PROFILING for sure. Unless the overhead is
> high, I'd keep the rest.
>
I'm not sure if any of this and auditd can be made modules. Seems like
stuff that'd have to just be around from the start. Things I'd like to
be able to pop out though.
I believe BSD process accounting CAN be built as a module...
>> Finally, I'm noticing a lot of stuff can be built as modules,
>> but is built in. Networking in its entirety; sound drivers;
>> mouse; and USB (the mouse looks like it's PS2)
>
> I have a strong reason to want modular libertas: bug #46.
>
> I suggest avoiding any situation where multiple modules need
> to be loaded. (one depends on another)
>
There are different schools of thought on this, in general purely
aesthetics based. One major thing however is all these extra file
systems like ext2 (the USB based stuff boots from ext3) or NFS (server?)
being built right into the kernel.
>> In the current dyntick scheme the regular clock interrupt still
>> happens when the processor is busy - it's only disabled when
>> things go idle. So you still need to set HZ to something.
>> It also sets the resolution of much of the timekeeping within
>> the kernel.
>
> Since there are no clock ticks when idle, you may as well go
> with 1000. It's better for music and video.
>
Good idea!
>>>> I'd keep the debug symbols (which shouldn't cost any memory
>>>> at runtime).
>>> Possibly not. The kernel runs inside one giant huge page doesn't it?
>>> 4MiB read-write-execute...
>> Not on the Geode: we don't have MTRRs, so I guess the kernel
>> is being mapped by 4KB pages.
>
> The main kernel runs in 4 MB or 2 MB pages on any system with
> the MMU capabilities of the Pentium. This works on the Geode.
> It has nothing to do with MTRRs, which are used to control the
> cache attributes. Kernel modules reside in regular 4 KB pages.
>
> Those debug symbols are required so that "ps -el" can tell you
> where a process is stuck. Better:
>
> ps -emostat,wchan:22,pid,tid,pcpu,comm,args
>
I did not know about this! :)
> Also, do not remove hugetlbfs. One could use that for speed
> in programs that deal with big arrays. I've actually seen the
> difference in a performance class I took. It can really matter.
Nods. That comment was because someone said there were no huge pages on
the Geode, which would render hugetlbfs useless. It's perfectly useful
if you have huge pages.
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
--
Bring back the Firefox plushy!
http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good
https://bugzilla.mozilla.org/show_bug.cgi?id=322367
More information about the Devel
mailing list