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