[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-amd64
Subject:    [gentoo-amd64]  Re: Re: SMP
From:       "Duncan" <1i5t5.duncan () cox ! net>
Date:       2006-05-27 16:44:12
Message-ID: e59vkr$apc$1 () sea ! gmane ! org
[Download RAW message or body]

"Mihir Sevak" <mihir.sevak@gmail.com> posted
48fcf8860605270704u4a75166pe201375a6483706b@mail.gmail.com, 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

-- 
gentoo-amd64@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]