"Mihir Sevak" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 27 May 2006 10:04:10 -0400:
> I thank you very much. Being little specific about my objective is i am > thinking of an > embedded system which can give me a very high processing speed. In other > words i wouldn't have much memory or other resources. Also i have to take > charge of the process scheduling as much as i can. So if i understand > correct i would be better off by > looking into kernal code rather than using other scheduling utilitis. > right??? For embedded, I'd probably look at both, particularly since you are looking at a low memory situation. For the kernel, there are a number of optimizations possible for low memory, including the new "SLOB Allocator" in place of the traditional "SLAB Allocator". Again, I don't claim to be an expert, but I do regularly run -rc kernels and track the changelog, and as a result, seem to have at least a better than average grip on what the latest changes might be there. AFAIK, SLOB is for embedded units without IOMMU. It was news to me that such a thing would even be available on amd64 hardware, but apparently it is, as the option is active and can be selected in menuconfig, even with SMP. Also look at the other small system options (under general setup, configure standard kernel features). You can either just try them and see how they work (my usual approach if it looks reasonable), or google for more info, if needed. As for the userspace side, AFAIK, basically those are tools that make give you a higher level kernel interface. You can either use the userland tools as they are, or go researching the kernel interface and the userland tool sources to see what they do and how, and go from there. Depending on just how demanding your embedded situation is going to be, it's likely that you could make your own tools leaner and meaner than the general purpose userspace ones, as yours could be specifically targeted to your specific application. Whether it's worth doing, however, would depend on just how tight you are squeezed for memory and CPU efficiency, and how large a subset of the functionality of the general purpose tools you need to retain. If you can hard code a specific value into the kernel rather than maintaining the tweaking machinery both in-kernel and in-userspace, you'll certainly save that many KB of memory over supporting the tweaking machinery. Again, this is just at a very general level, as I don't claim to be an expert in the field at all. I only follow it on a view from 10km level as I see it come up in various discussions. Actually, I don't even claim to know C programming, tho I know the higher level principles involved and enough to get a thrill out of following along with various kernel and other debates. One hint, hopefully useful. If you decide to go doing much with the kernel, at least go check what might be written on your kernel subtopic of interest over at lwn.net. Jon Corbet, the editor/author, is well respected in the kernel community, both for the weekly kernel page coverage, and for his book on the kernel from a kernel driver developer perspective. The fact that he had a presentation at the last OLS (Ottawa Linux Symposium), if you know anything about it, should by itself tell you the level of respect he has among the kernel folks. If nothing else, lwn should serve as a good launch pad toward additional research, far deeper than you are likely to get from a list like this (except as a pointer to things like lwn =8^). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
