Re: Kernel configuration options
On Thu, 3 Jan 2008, Mitch Bradley wrote: > [EMAIL PROTECTED] wrote: >> >> ... the biggest benefits look like they would be in cleaning up the >> userspace boot process. there is a _lot_ of stuff started that may not be >> needed in the stable hardware environment of the XO laptop where there is >> really only one program active at a time (dbus comes to mind) >> >> remember that XO is based on Fedora, which is designed for maximum features >> and flexibility, not for efficiancy. This translates into poor performance >> for the user. >> > > Please add specific suggestions to http://dev.laptop.org/ticket/4349 . That > ticket serves as a collector for boot speedup experiments. thanks for the pointer to the correct place. should there be a link to this fairly prominently in the main wiki? or in the welcome message to this list? there are probably a bunch of similar links that new subscribers should be aware of so that they don't waste everyone's time asking the same questions or making the same suggestions > Tested results are especially useful; off-the-cuff ideas less so. definantly. I haven't had time to dive in much yet (and frankly, the tangle of processes in Fedora is one reason I've preferred to avoid using it in the first place), but anything posted as a formal suggestion needs to be tested. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
[EMAIL PROTECTED] wrote: > > ... the biggest benefits look like they would be in > cleaning up the userspace boot process. there is a _lot_ of stuff started > that may not be needed in the stable hardware environment of the XO laptop > where there is really only one program active at a time (dbus comes to > mind) > > remember that XO is based on Fedora, which is designed for maximum > features and flexibility, not for efficiancy. This translates into poor > performance for the user. > Please add specific suggestions to http://dev.laptop.org/ticket/4349 . That ticket serves as a collector for boot speedup experiments. Tested results are especially useful; off-the-cuff ideas less so. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Kernel configuration options
one good reason to avoid modules where we cn is that each module that gets loaded wastes a partial page of memory (arguably ~2k/module on average), on a system with only 256M ram this can add up to be a noticable amount of memory lost if you go the route some advocate and make everything a module. and given that there is only 1G of 'disk' available to the system to store modules, I would argue that trying to provide modules for all sorts of esoteric hardware (USB video was mentioned) is a waste of resources. make the other modules available for download and installation as needed, but don't eat up the space otherwise modules are useful for when you have hardware that's used very infrequently and the driver is fairly large, but I don't think that there are many cases where this is a good argument. I've always built my kernels as monolithic as possible, even for my laptops, so I know that it can be done (except a few drivers that need to load firmware). while there are some (vocal) kernel developers who feel that the kernel shouldn't even understand disk partitioning, and that everything should be a module, there are many others who feel that the kernel should not require external assistance for simple situations. Linus has commented that he also builds his kernels monolithic rather then with lots of modules, so we're in good company if we choose to do the same. I haven't compiled my own kernels for the XO yet, so I don't know how much can be tweaked to reduce the size, but it looks like there is some room for tweaking. however, the biggest benefits look like they would be in cleaning up the userspace boot process. there is a _lot_ of stuff started that may not be needed in the stable hardware environment of the XO laptop where there is really only one program active at a time (dbus comes to mind) remember that XO is based on Fedora, which is designed for maximum features and flexibility, not for efficiancy. This translates into poor performance for the user. I know that the XO has a slow CPU, but I just recently retired a 333MHz laptop that I was running Slackware on, and it was far more responsive then the XO is (even with a faster CPU and a solid-state drive). there is a LOT of room for improvement here. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: > Albert Cahalan wrote: >> [various people] >> Since there are no clock ticks when idle, you may as well go >> with 1000. It's better for music and video. > > Good idea! We can't enable it without doing some power profiling first. cjb has been doing lots of work in this area, so I wonder what he thinks about it. Many distros compromise on 250Hz, which provides more than enough precision for humans, while being 4x cheaper than 1000Hz. >> 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! :) Me neither... "emostat", lol! >> 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. It was me, but I was evidently mistaken. Still, I wonder if there are actually any real users of the hugetlb facility in our distro or even in the rest of Fedora. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
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@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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
[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. > 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) > 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. >>> 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 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: > YES. You can mix and match your page sizes, have some pages 4MiB and > some 4KiB. If a block of i.e. the heap is 4MiB long, the kernel can > technically relocate all 1024 involved pages so they're physically > contiguous and aligned to a 4MiB boundary, and then remap them as one > huge page. It would have to handle an munmap() or brk() (shrinking) > call by breaking it back up; but it could be done. There's only partial vm support for 4MB pages in Linux, and only for special cases. On a few systems, I get: trinity:~# cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize: 4096 kB bender:~# cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB [EMAIL PROTECTED] ~]$ cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize:16384 kB daneel:~# cat /proc/meminfo | grep Huge (no output) I wonder if huge pages are even used for anything? > There's no reason with video memory sizes like 4M, 8M, 16M, 32M, 64M, > 256M, and these days even 512M that these kinds of mappings should use > 4KiB pages anymore. Unlike the heap or anonymous mmap() segments, video > memory doesn't change size and doesn't eat physical memory (*cough*); > and unlike file-backed shared mmap() segments, you can't free up space > by evicting the contents from memory if nobody's using it. It's probably not being done because of this feature is very recent, and maybe immature. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Jordan Crouse wrote: > On 02/01/08 08:18 -0500, Bernardo Innocenti wrote: >> Tom Sylla wrote: >> >>> http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware >>> has: >>> msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize >>> >>> which is setting the framebuffer as write-combining. (the "write >>> through" comment is incorrect) >> This takes care of the physical mapping, but how would userspace >> be able to mmap the framebuffer into virtual memory without >> additional MMU programming? >> >> I was under the impression that we also need to cover the whole >> region with small 4KB MMU pages. This degrades performance >> somewhat due to TLB misses when the CPU accesses the framebuffer. > > Well, in an ideal world, we wouldn't need to read framebuffer so much > that any performance hit would be small, especially with as big a > offscreen buffer as we have. > > I know that this is not an ideal world, and there is some X breakage > that reads and writes a lot from the framebuffer, but quite frankly, > thats the least of our speed worries right now. > > But out of curiosity, what you would you have us do differently? Are you > advocating that we move to 4Mb pages? > YES. You can mix and match your page sizes, have some pages 4MiB and some 4KiB. If a block of i.e. the heap is 4MiB long, the kernel can technically relocate all 1024 involved pages so they're physically contiguous and aligned to a 4MiB boundary, and then remap them as one huge page. It would have to handle an munmap() or brk() (shrinking) call by breaking it back up; but it could be done. There's no reason with video memory sizes like 4M, 8M, 16M, 32M, 64M, 256M, and these days even 512M that these kinds of mappings should use 4KiB pages anymore. Unlike the heap or anonymous mmap() segments, video memory doesn't change size and doesn't eat physical memory (*cough*); and unlike file-backed shared mmap() segments, you can't free up space by evicting the contents from memory if nobody's using it. > Jordan > -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
On 02/01/08 08:18 -0500, Bernardo Innocenti wrote: > Tom Sylla wrote: > > > http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware > > has: > > msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize > > > > which is setting the framebuffer as write-combining. (the "write > > through" comment is incorrect) > > This takes care of the physical mapping, but how would userspace > be able to mmap the framebuffer into virtual memory without > additional MMU programming? > > I was under the impression that we also need to cover the whole > region with small 4KB MMU pages. This degrades performance > somewhat due to TLB misses when the CPU accesses the framebuffer. Well, in an ideal world, we wouldn't need to read framebuffer so much that any performance hit would be small, especially with as big a offscreen buffer as we have. I know that this is not an ideal world, and there is some X breakage that reads and writes a lot from the framebuffer, but quite frankly, thats the least of our speed worries right now. But out of curiosity, what you would you have us do differently? Are you advocating that we move to 4Mb pages? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
On 02/01/08 08:01 -1000, Mitch Bradley wrote: > John Richard Moser wrote: > > Bernardo Innocenti wrote: > > > >> Tom Sylla wrote: > >> > >> > >>> http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware > >>> has: > >>> msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize > >>> > >>> which is setting the framebuffer as write-combining. (the "write > >>> through" comment is incorrect) > >>> > >> This takes care of the physical mapping, but how would userspace > >> be able to mmap the framebuffer into virtual memory without > >> additional MMU programming? > >> > >> I was under the impression that we also need to cover the whole > >> region with small 4KB MMU pages. This degrades performance > >> somewhat due to TLB misses when the CPU accesses the framebuffer. > >> > >> > > > > I missed whether or not the Geode actually has 4MiB huge pages, I > > thought someone said it does. This being the case, why can't you access > > the 16 (or was it 24?) MiB of memory via a handful (about 1/1024th) of > > huge mappings? Does x86 MMU not allow for huge MMIO? > > > > The Geode GX has 64 TLB entries right? I don't know how many the Geode > > LX has, or if there's an L2 TLB. Obviously, though, this would be a > > major performance boon, what with there being (assuming 24MiB of vram) 5 > > probably often used mappings instead of 5120 in an often-used set with a > > probably uneven distribution. > > > > The magnitude of the performance benefit is not at all obvious. The > Geode's graphics accelerator uses physical addressing. True - but the framebuffer is also mapped into virtual space for the benefit of the kernel and userspace, and our graphics software reads directly from the mapped memory more then it should. This is especially true for composite operations, which for better or for worse, comprise most of our operations these days, thanks to Cairo and friends. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: > John Richard Moser wrote: >> Bernardo Innocenti wrote: >> >>> Tom Sylla wrote: >>> >>> [...] >> The Geode GX has 64 TLB entries right? I don't know how many the >> Geode LX has, or if there's an L2 TLB. Obviously, though, this would >> be a major performance boon, what with there being (assuming 24MiB of >> vram) 5 probably often used mappings instead of 5120 in an often-used >> set with a probably uneven distribution. >> > > The magnitude of the performance benefit is not at all obvious. The > Geode's graphics accelerator uses physical addressing. > But X doesn't. I was more thinking from the POV of X11 writing textures/icons into it, which when you switch applications may or may not wind up running all over the place and stamping out 20-30 TLB entries. I'm still not sure how it works. > >> >>> But I must confess I have limited understanding of the Geode >>> architecture, so I may be overlooking something. >>> >>> >> >> > > -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: > Bernardo Innocenti wrote: > >> Tom Sylla wrote: >> >> >>> http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware >>> has: >>> msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize >>> >>> which is setting the framebuffer as write-combining. (the "write >>> through" comment is incorrect) >>> >> This takes care of the physical mapping, but how would userspace >> be able to mmap the framebuffer into virtual memory without >> additional MMU programming? >> >> I was under the impression that we also need to cover the whole >> region with small 4KB MMU pages. This degrades performance >> somewhat due to TLB misses when the CPU accesses the framebuffer. >> >> > > I missed whether or not the Geode actually has 4MiB huge pages, I > thought someone said it does. This being the case, why can't you access > the 16 (or was it 24?) MiB of memory via a handful (about 1/1024th) of > huge mappings? Does x86 MMU not allow for huge MMIO? > > The Geode GX has 64 TLB entries right? I don't know how many the Geode > LX has, or if there's an L2 TLB. Obviously, though, this would be a > major performance boon, what with there being (assuming 24MiB of vram) 5 > probably often used mappings instead of 5120 in an often-used set with a > probably uneven distribution. > The magnitude of the performance benefit is not at all obvious. The Geode's graphics accelerator uses physical addressing. > >> But I must confess I have limited understanding of the Geode >> architecture, so I may be overlooking something. >> >> > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: > Tom Sylla wrote: > >> http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware >> has: >> msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize >> >> which is setting the framebuffer as write-combining. (the "write >> through" comment is incorrect) > > This takes care of the physical mapping, but how would userspace > be able to mmap the framebuffer into virtual memory without > additional MMU programming? > > I was under the impression that we also need to cover the whole > region with small 4KB MMU pages. This degrades performance > somewhat due to TLB misses when the CPU accesses the framebuffer. > I missed whether or not the Geode actually has 4MiB huge pages, I thought someone said it does. This being the case, why can't you access the 16 (or was it 24?) MiB of memory via a handful (about 1/1024th) of huge mappings? Does x86 MMU not allow for huge MMIO? The Geode GX has 64 TLB entries right? I don't know how many the Geode LX has, or if there's an L2 TLB. Obviously, though, this would be a major performance boon, what with there being (assuming 24MiB of vram) 5 probably often used mappings instead of 5120 in an often-used set with a probably uneven distribution. > But I must confess I have limited understanding of the Geode > architecture, so I may be overlooking something. > -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Tom Sylla wrote: > http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware > has: > msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize > > which is setting the framebuffer as write-combining. (the "write > through" comment is incorrect) This takes care of the physical mapping, but how would userspace be able to mmap the framebuffer into virtual memory without additional MMU programming? I was under the impression that we also need to cover the whole region with small 4KB MMU pages. This degrades performance somewhat due to TLB misses when the CPU accesses the framebuffer. But I must confess I have limited understanding of the Geode architecture, so I may be overlooking something. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
On Jan 1, 2008 9:50 PM, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > So I wonder why we couldn't use these to speed up access > to the framebuffer in the amd_drv X driver. I don't understand, this was always taken care of. http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware has: msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize which is setting the framebuffer as write-combining. (the "write through" comment is incorrect) I don't have current hardware to check if this is the way things are at run-time (maybe something over-writes that register later), but it was all working fine at some point in the past. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Tom Sylla wrote: >> Not on the Geode: we don't have MTRRs, so I guess the kernel >> is being mapped by 4KB pages. > > 4MB page support is unrelated to MTRR support. (one is related to linear > addresses, the other physical addresses; please see the Intel or AMD > documentation on paging and caching) > > Geode LX supports 4MB pages, it is reported as such in CPUID, and should > be used by the kernel. > > Also note that Geode LX has "RCONFs" instead of MTRRs, which have the > same functionality, and they are all programmed properly by the firmware. So I wonder why we couldn't use these to speed up access to the framebuffer in the amd_drv X driver. Jordan, what do you think? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: >>> 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. 4MB page support is unrelated to MTRR support. (one is related to linear addresses, the other physical addresses; please see the Intel or AMD documentation on paging and caching) Geode LX supports 4MB pages, it is reported as such in CPUID, and should be used by the kernel. Also note that Geode LX has "RCONFs" instead of MTRRs, which have the same functionality, and they are all programmed properly by the firmware. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: > Bernardo Innocenti wrote: >> John Richard Moser wrote: >>> (Do I need a developer's key or smth?) >> Yes, you do need a developer key. What is an smth? > > something Gosh, as you might have guessed, I'm not a native English speaker :-) >> Not on the Geode: we don't have MTRRs, so I guess the kernel >> is being mapped by 4KB pages. > > Remove hugetlbfs then. Good point. > Would you boot off the kernel on the flash and then load the system from > the USB or SD, or use a kernel on the SD card? You could do both ways by tweaking the olpc.fth boot script as you wish. But I guess keeping the kernel with its OS would be the way to go in most cases. > So this raises the question: By parallelizing boot and using an > event-driven init system like Ubuntu's Upstart, could you actually get > to running application code before loading the modules; and then set up > all the hardware while more CPU-bound parts of the boot process run? As someone said a few days ago (was it dwmw?), there's not much you can gain by parallelizing boot on the XO, because I/O on the flash is pretty much synchronous and CPU bound. And we only have one CPU, of course. But it turns out that running X very soon during the startup process is quite easy. People do not realize that, by today standards, the X server is a very small program. It starts in less than one second off warm buffer caches. And, more importantly, it has almost no external dependencies. SIDE NOTE: some genius recently made the X server depend on OpenSSL in git so they could use MD5 as a hashing algorithm for traditional fonts. But I guess someone will undo this brain damage soon or later :-) > Sort of bring up the system while all the devices are being initialized, > just as long as graphics + keyboard + mouse are up for X to start when > it gets there. No need to wait for input devices before you start X: with the new input hotplug system, you can dynamically add mice and kbds after the fact. I was planning to do that for Update.2 if I ever find the time. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: > John Richard Moser wrote: > >>> Please, build a kernel with the changes you consider useful, >>> and make it available somewhere, along with your proposed >>> config patch. Please make sure that the resulting kernel >>> also still works on QEMU and VMware. >>> >> The base hardware drivers built in supports qemu and vmware? > > Yes, but it doesn't take that much. It's probably just a > pci IDE controller and the vesafb. > > >> Looks like I gotta read up on the wiki about how to rebuild the kernels >> (again). It seems I can alter Grub to do what I want afterwards though. >> (Do I need a developer's key or smth?) > > Yes, you do need a developer key. What is an smth? > something > Rebuilding the kernel RPM is less than trivial. You may > prefer just building the kernel and then copying it on the > target with a stupid script like this one: > > tar -C $stagedir -czf - . | ssh [EMAIL PROTECTED] tar -C $destdir -xvzf - So glad right now that ssh doesn't allow blank password log-in. So very glad. > > >>> Extra bonus points if you can give hard numbers on memory >>> saving and performance gains. >>> >> Black art ;) > > Well, "size vmlinux" may be a lower bound approximation > for the memory saving. Combined with some /proc/slabinfo > magic you'd get closer. > > As you say, performance is hard to measure. Shell scripts > tend to be good kernel benchmarks because they create lots > of processes, file descriptors, and do a lot of I/O. > Point taken. >>> 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. > Remove hugetlbfs then. > But anyway, aren't the symbols in a separate ELF section? > So probably they end up in the vmlinuz binary too, but > I've not checked. > > >>> Because of this, I think all the modules required for booting >>> off jffs2 and ext3 need to be linked in :-( >> I think you can omit booting off ext3 for the final product. > > Hmmm, people may like to boot off USB and SD, wouldn't they? > We're talking about a very small saving anyway... Would you boot off the kernel on the flash and then load the system from the USB or SD, or use a kernel on the SD card? > > >> There is load-time consideration to be made about loading everything as >> modules (camera, USB, mouse, all of networking, sound, etc) and leaving >> the essentials (flash, display, keyboard, jffs2). Even if you leave >> networking and all the 100%-always-loaded modules compiled in, however, >> there's no need for things like 30 types of file systems. > > We still have plenty of places where we could recover several > *seconds* of boot time with just minor changes. So I don't think > we should worry too much about module load time, which is probably > very fast. > > In my experience, module load time is usually dominated by the work > being done in the init function, which sometimes involves sleeping > or performing slow I/O (i2c, serial, USB...). This time would also > be spent in the monolithic kernel. > So this raises the question: By parallelizing boot and using an event-driven init system like Ubuntu's Upstart, could you actually get to running application code before loading the modules; and then set up all the hardware while more CPU-bound parts of the boot process run? Sort of bring up the system while all the devices are being initialized, just as long as graphics + keyboard + mouse are up for X to start when it gets there. > >> I'd personally leave out ipv4 and ipv6 and just load them at boot time; >> I'd rather not have ipv6 loaded right now, and ipv6 infrastructures >> should run without ipv4 (some apps will probably complain about no >> 127.0.0.1...); but this is just nitpicking. > > I agree with you. > > >> Really I like a tiny core kernel and a bunch of modules but as >> I said, increases the time needed to boot. > > I once again agree with you, except that I don't think > the load time increase will be problematic on the XO. > -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: >> Please, build a kernel with the changes you consider useful, >> and make it available somewhere, along with your proposed >> config patch. Please make sure that the resulting kernel >> also still works on QEMU and VMware. >> > > The base hardware drivers built in supports qemu and vmware? Yes, but it doesn't take that much. It's probably just a pci IDE controller and the vesafb. > Looks like I gotta read up on the wiki about how to rebuild the kernels > (again). It seems I can alter Grub to do what I want afterwards though. > (Do I need a developer's key or smth?) Yes, you do need a developer key. What is an smth? Rebuilding the kernel RPM is less than trivial. You may prefer just building the kernel and then copying it on the target with a stupid script like this one: ---8<--- dest=18.85.46.119 stagedir=stage #vservers destdir=/versions/boot/current/boot #sane #destdir=/ set -x mkdir -p $stagedir/boot make INSTALL_MOD_PATH=$stagedir modules_install make bzImage cp -a arch/i386/boot/bzImage $stagedir/boot/vmlinuz cp -a System.map $stagedir/boot tar -C $stagedir -czf - . | ssh [EMAIL PROTECTED] tar -C $destdir -xvzf - ---8<--- >> Extra bonus points if you can give hard numbers on memory >> saving and performance gains. >> > > Black art ;) Well, "size vmlinux" may be a lower bound approximation for the memory saving. Combined with some /proc/slabinfo magic you'd get closer. As you say, performance is hard to measure. Shell scripts tend to be good kernel benchmarks because they create lots of processes, file descriptors, and do a lot of I/O. >> 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. But anyway, aren't the symbols in a separate ELF section? So probably they end up in the vmlinuz binary too, but I've not checked. >> Because of this, I think all the modules required for booting >> off jffs2 and ext3 need to be linked in :-( > > I think you can omit booting off ext3 for the final product. Hmmm, people may like to boot off USB and SD, wouldn't they? We're talking about a very small saving anyway... > There is load-time consideration to be made about loading everything as > modules (camera, USB, mouse, all of networking, sound, etc) and leaving > the essentials (flash, display, keyboard, jffs2). Even if you leave > networking and all the 100%-always-loaded modules compiled in, however, > there's no need for things like 30 types of file systems. We still have plenty of places where we could recover several *seconds* of boot time with just minor changes. So I don't think we should worry too much about module load time, which is probably very fast. In my experience, module load time is usually dominated by the work being done in the init function, which sometimes involves sleeping or performing slow I/O (i2c, serial, USB...). This time would also be spent in the monolithic kernel. > I'd personally leave out ipv4 and ipv6 and just load them at boot time; > I'd rather not have ipv6 loaded right now, and ipv6 infrastructures > should run without ipv4 (some apps will probably complain about no > 127.0.0.1...); but this is just nitpicking. I agree with you. > Really I like a tiny core kernel and a bunch of modules but as > I said, increases the time needed to boot. I once again agree with you, except that I don't think the load time increase will be problematic on the XO. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: > From a security standpoint, there is an advantage to building in > everything. The main kernel is verified with a crypto signature before > it is executed. Loading a module without first verifying a > similarly-strong signature weakens the security. > Loadable kernel modules are enabled in the config. This argument is moot. You can sign modules, RHEL supports this by default and has a boot option for it. More interesting, some cute hacks have been done before to get write access to the kernel through /dev/(k)mem, evading the "protection" of kernels not supporting modules. This is of course fixable. > Modules are a good idea for kernels that are intended to run on a wide > variety of hardware. I am in favor of treating XO like an appliance and > making the kernel as monolithic as possible. I don't favor loading in modules for Joliet and other CD-ROM stuff, for RAMFS (which shouldn't be used anyway, use TMPFS), ROMFS (is this even used?), NTFS, ext2, ext3, etc. that's not with the system by default. All these can be loadable modules. > > ___ > Devel mailing list > Devel@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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: > John Richard Moser wrote: >> I'm not sure about some of the kernel configuration options. A few >> minor things stick out in my mind; I don't know the rationale behind >> some of these things and am curious about developer decisions and >> thoughts on how to build the kernel. >> >> * CONFIG_NO_HZ + CONFIG_HZ=100? >> * SLAB vs SLUB >> * Some debugging stuff >> * More debugging stuff >> * Building stuff as modules > > Please, build a kernel with the changes you consider useful, > and make it available somewhere, along with your proposed > config patch. Please make sure that the resulting kernel > also still works on QEMU and VMware. > The base hardware drivers built in supports qemu and vmware? Looks like I gotta read up on the wiki about how to rebuild the kernels (again). It seems I can alter Grub to do what I want afterwards though. (Do I need a developer's key or smth?) > Extra bonus points if you can give hard numbers on memory > saving and performance gains. > Black art ;) > As a super-quick-and-dirty test, note that /home/olpc/.boot_time > records the time it takes to get from kernel startup to the > X session. We can expect that time to be slighly influenced > by your improvements because booting exercises several kernel > subsystems, including vfs, slab, forks and mmaps. > Interesting! I didn't know this. Boot chart was pulled out for something else that I don't know how to use yet as well. > >> First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of >> the kernel's general configuration? As I understand, these options >> should be mutually exclusive because CONFIG_HZ is a parameter of a >> scheduler using a different methodology than CONFIG_NO_HZ... > > Probably a (harmless) leftover of editing the .config manually. > > >> Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is >> supposed to be a faster generic replacement for SLAB.[1] Is there a >> reason the XO doesn't use it? > > Don't expect too much out of it: >http://lwn.net/Articles/261868/ > Point taken. > But I still think we should try it and maybe use it. > > >> I'm also noticing some things like KALLSYMS and BUG(), BSD process >> accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on >> a true embedded device I'd say remove 'em but I can't justify it here... >> BSD process accounting and auditd support though? > > 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... > > >> In the same line, a lot of debugging options are in use. I'm using >> Build 653, I guess it may be a developer's build and thus there's a lot >> of debugging stuff; but in the final should things like CONFIG_PROFILING >> , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, >> CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, >> CONFIG_DEBUG_SPINLOCK ... be removed? > > I side with M.Edward on keeping oprofile support, which does > not slowdown the system and can be built as a module. > > >> Finally, I'm noticing a lot of stuff can be built as modules, but is >> built in. > > Go for it! But please note that we're using a weird initrd > that doesn't contain modules (or maybe does, but cannot easily > be regenerated along with the kernel). > > Because of this, I think all the modules required for booting > off jffs2 and ext3 need to be linked in :-( > I think you can omit booting off ext3 for the final product. There is load-time consideration to be made about loading everything as modules (camera, USB, mouse, all of networking, sound, etc) and leaving the essentials (flash, display, keyboard, jffs2). Even if you leave networking and all the 100%-always-loaded modules compiled in, however, there's no need for things like 30 types of file systems. I'd personally leave out ipv4 and ipv6 and just load them at boot time; I'd rather not have ipv6 loaded right now, and ipv6 infrastructures should run without ipv4 (some apps will probably complain about no 127.0.0.1...); but this is just nitpicking. Really I like a tiny core kernel and a bunch of modules but as I said, increases the time needed to boot. -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: > I would argue that support for some reasonable subset of important USB > devices - e.g. mass storage, network, and HID - should be compiled-in > and we should support the rest of the wide world of USB from userland, > e.g. with libusb. There are no libusb based drivers at this time for many, many popular USB devices. And in some cases, such as my $30 TV dongle, there's no way to pipe data back into the kernel to reach the appropriate layer (v4l2 and alsa in this case). We'd better rethink our security strategy so that we can verify kernel modules somehow and/or prevent the user from replacing them. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: > I'm not sure about some of the kernel configuration options. A few > minor things stick out in my mind; I don't know the rationale behind > some of these things and am curious about developer decisions and > thoughts on how to build the kernel. > > * CONFIG_NO_HZ + CONFIG_HZ=100? > * SLAB vs SLUB > * Some debugging stuff > * More debugging stuff > * Building stuff as modules Please, build a kernel with the changes you consider useful, and make it available somewhere, along with your proposed config patch. Please make sure that the resulting kernel also still works on QEMU and VMware. Extra bonus points if you can give hard numbers on memory saving and performance gains. As a super-quick-and-dirty test, note that /home/olpc/.boot_time records the time it takes to get from kernel startup to the X session. We can expect that time to be slighly influenced by your improvements because booting exercises several kernel subsystems, including vfs, slab, forks and mmaps. > First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of > the kernel's general configuration? As I understand, these options > should be mutually exclusive because CONFIG_HZ is a parameter of a > scheduler using a different methodology than CONFIG_NO_HZ... Probably a (harmless) leftover of editing the .config manually. > Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is > supposed to be a faster generic replacement for SLAB.[1] Is there a > reason the XO doesn't use it? Don't expect too much out of it: http://lwn.net/Articles/261868/ But I still think we should try it and maybe use it. > I'm also noticing some things like KALLSYMS and BUG(), BSD process > accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on > a true embedded device I'd say remove 'em but I can't justify it here... > BSD process accounting and auditd support though? I'd keep the debug symbols (which shouldn't cost any memory at runtime). > In the same line, a lot of debugging options are in use. I'm using > Build 653, I guess it may be a developer's build and thus there's a lot > of debugging stuff; but in the final should things like CONFIG_PROFILING > , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, > CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, > CONFIG_DEBUG_SPINLOCK ... be removed? I side with M.Edward on keeping oprofile support, which does not slowdown the system and can be built as a module. > Finally, I'm noticing a lot of stuff can be built as modules, but is > built in. Go for it! But please note that we're using a weird initrd that doesn't contain modules (or maybe does, but cannot easily be regenerated along with the kernel). Because of this, I think all the modules required for booting off jffs2 and ext3 need to be linked in :-( -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Bernardo Innocenti wrote: > Mitch Bradley wrote: > > >> From a security standpoint, there is an advantage to building in >> everything. The main kernel is verified with a crypto signature before >> it is executed. Loading a module without first verifying a >> similarly-strong signature weakens the security. >> >> Modules are a good idea for kernels that are intended to run on a wide >> variety of hardware. I am in favor of treating XO like an appliance and >> making the kernel as monolithic as possible. >> > > Uh-oh... Does our security system really depend on this? > > Reducing the number of modules is not going to help, because > you only need to load a single module to tap into the kernel. > > Building everything statically and disabling module loading > is also not an option if you want half decent support for > USB devices. Note that USB also brings in SCSI, DVB, and > a lot more. > I would argue that support for some reasonable subset of important USB devices - e.g. mass storage, network, and HID - should be compiled-in and we should support the rest of the wide world of USB from userland, e.g. with libusb. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: > From a security standpoint, there is an advantage to building in > everything. The main kernel is verified with a crypto signature before > it is executed. Loading a module without first verifying a > similarly-strong signature weakens the security. > > Modules are a good idea for kernels that are intended to run on a wide > variety of hardware. I am in favor of treating XO like an appliance and > making the kernel as monolithic as possible. Uh-oh... Does our security system really depend on this? Reducing the number of modules is not going to help, because you only need to load a single module to tap into the kernel. Building everything statically and disabling module loading is also not an option if you want half decent support for USB devices. Note that USB also brings in SCSI, DVB, and a lot more. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
M. Edward (Ed) Borasky wrote: > Mitch Bradley wrote: > >> From a security standpoint, there is an advantage to building in >> everything. The main kernel is verified with a crypto signature before >> it is executed. Loading a module without first verifying a >> similarly-strong signature weakens the security. >> >> Modules are a good idea for kernels that are intended to run on a wide >> variety of hardware. I am in favor of treating XO like an appliance and >> making the kernel as monolithic as possible. >> > > I'm not familiar with the security stuff in general or this case in > particular. But I think the "trend" in the Linux community has been > towards more flexibility, moving stuff from kernel space to user space, etc. > It depends on which part of the Linux community you focus on. In the desktop sub-community, Linux runs on computers where 98% of the units of any individual model run Windows. If you were to take a random sampling of 1000 Linux desktop users, you would probably find at least 300 different hardware platforms. In that scenario, flexibility is absolutely necessary, because Linux doesn't own any platform. The situation is obviously different for Linux in embedded applications like little router boxes, and in server applications like Google server farms, but I expect that in many of those applications, the kernel is largely hard-compiled. These non-desktop environments, while they probably account for a very substantial portion (perhaps even the marjority) of the total Linux installed base, don't have much "community visibility", because they are often done "in house" by hardware manufacturers and large organizations. > Then again, since the *hardware* is soldered onto the mainboard and > can't be easily expanded, why shouldn't the *kernel* be just as > inflexible? ;) > There seems to be an implied value judgment that "inflexible" is bad. There is a tradeoff between flexibility and reliability. One of the reasons why Macintoshes "just work" is because Apple doesn't have to deal with a near-infinite array of different hardware. One of my goals for OLPC is to make a machine that "just works". When I was younger, I used to be excited by every shiny new thing, but over time, I got pretty tired of spending a lot of time fixing stuff that was continually broken due to random churn in hardware and software. EMACS (my favorite editor) is perhaps the most flexible editor on the planet. One of its core flexibilities is the ability to rebind any key to any function. That makes it difficult, bordering on impossible, to support EMACS in a community of diverse users, because you never know what you are dealing with for any given user. Jaron Lanier, in this controversial essay http://discovermagazine.com/2007/dec/long-live-closed-source-software argues that pinning down large portions of a system can be very advantageous in some respects. Everything is a tradeoff. > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
Mitch Bradley wrote: > From a security standpoint, there is an advantage to building in > everything. The main kernel is verified with a crypto signature before > it is executed. Loading a module without first verifying a > similarly-strong signature weakens the security. > > Modules are a good idea for kernels that are intended to run on a wide > variety of hardware. I am in favor of treating XO like an appliance and > making the kernel as monolithic as possible. I'm not familiar with the security stuff in general or this case in particular. But I think the "trend" in the Linux community has been towards more flexibility, moving stuff from kernel space to user space, etc. Then again, since the *hardware* is soldered onto the mainboard and can't be easily expanded, why shouldn't the *kernel* be just as inflexible? ;) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: > I'm also noticing some things like KALLSYMS and BUG(), BSD process > accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on > a true embedded device I'd say remove 'em but I can't justify it here... > BSD process accounting and auditd support though? Yeah ... I run stuff like that in *my* kernels, but I'm a kernel geek. Does that stuff need to be in a machine in a village school in Rwanda? P.S.: I do know a Red Hat geek in Nigeria. :) > > In the same line, a lot of debugging options are in use. I'm using > Build 653, I guess it may be a developer's build and thus there's a lot > of debugging stuff; but in the final should things like CONFIG_PROFILING > , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, > CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, > CONFIG_DEBUG_SPINLOCK ... be removed? I think I agree with you here with the possible exception of CONFIG_PROFILING aka "oprofile support". > > 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) can be loaded by HAL and UDEV, but this > will increase boot time (then again, HAL apparently needs to be fixed > anyway[2], so this could be encouraging?). More interesting to me > however is that EXT2, EXT3, Joliet, ZISOFS, RAMFS, NFS, and possibly > PROMFS because I don't think JFFS2 depends on it BUT I'm not sure if > it's used at some point before it can be loaded as a module. I'd keep as much as possible that's XO-specific and *always* going to be loaded built in. You're always going to need sound, mouse and keyboard, wireless and video, and I'd keep the core USB stuff built in as well, since that's really the only way to talk to the machine besides wireless. But the rest of it should be built as modules. The filesystems should be there (as modules). The XO is going to be talking to school servers, and there's no point in ruling out NFS, Samba, plugging in an external USB DVD reader/writer, etc. Again, the question is, "would a village in Rwanda format a USB stick ext3?" :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
I can't speak for the OLPC kernel folks, but here's a few thoughts: > First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of > the kernel's general configuration? As I understand, these options > should be mutually exclusive because CONFIG_HZ is a parameter of a > scheduler using a different methodology than CONFIG_NO_HZ... 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. > Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is > supposed to be a faster generic replacement for SLAB.[1] Is there a > reason the XO doesn't use it? I don't know why that decision was made, but SLUB is still new and still getting a few things shaken out of it. Using slab for the currently-shipped system makes sense to me. jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Kernel configuration options
I'm not sure about some of the kernel configuration options. A few minor things stick out in my mind; I don't know the rationale behind some of these things and am curious about developer decisions and thoughts on how to build the kernel. * CONFIG_NO_HZ + CONFIG_HZ=100? * SLAB vs SLUB * Some debugging stuff * More debugging stuff * Building stuff as modules First off I noticed CONFIG_NO_HZ=y and CONFIG_HZ=100; is this a quirk of the kernel's general configuration? As I understand, these options should be mutually exclusive because CONFIG_HZ is a parameter of a scheduler using a different methodology than CONFIG_NO_HZ... Another thing is I noticed CONFIG_SLAB=y, but the SLUB allocator is supposed to be a faster generic replacement for SLAB.[1] Is there a reason the XO doesn't use it? I'm also noticing some things like KALLSYMS and BUG(), BSD process accounting, and the like. KALLSYMS, BUG(), and printk() are useful; on a true embedded device I'd say remove 'em but I can't justify it here... BSD process accounting and auditd support though? In the same line, a lot of debugging options are in use. I'm using Build 653, I guess it may be a developer's build and thus there's a lot of debugging stuff; but in the final should things like CONFIG_PROFILING , CONFIG_KPROBES, CONFIG_DEBUG_FS, CONFIG_UNUSED_SYMBOLS, CONFIG_SCHEDSTATS, CONFIG_TIMER_STATS, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SPINLOCK ... be removed? 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) can be loaded by HAL and UDEV, but this will increase boot time (then again, HAL apparently needs to be fixed anyway[2], so this could be encouraging?). More interesting to me however is that EXT2, EXT3, Joliet, ZISOFS, RAMFS, NFS, and possibly PROMFS because I don't think JFFS2 depends on it BUT I'm not sure if it's used at some point before it can be loaded as a module. [1] http://lwn.net/Articles/229984/ [2] http://lwn.net/Articles/192214/ -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
