> As Linux moves on into the Unix mainstream, we need to self-evaluate
> the features of kernel that is so important where performance is
> concerned.
>
> I have not seen any performance HOWTO for Linux Kernel yet,
> especially one that is targetted to the Kernel developer, on how to
> write performance enhancing source code. (The nearest similar HOWTO
> is the Benchmarking Project,
I am willing to work on such a document. I already have some
sysadmin-targeted documents (linux/Documentation/sysctl/*) so
writing hacker-targeted onces should be fun and easy to do.
I _will_ need some help from guys like Linus, Alan, MINGO
and hpa, however, since I'm not that much of an expert on
the very fine details of performance enhancing.
My knowlegde can be compressed into the following:
- KISS
- shifts are faster than multiplies and divides
- compute-intensive code should be written in an
easily paralelizable way, ie. make sure that multiple
independant calculations are done in the inner level of
the loop. This is done so that the compiler can more
easily keep more branches of the CPU busy.
- write very very modular code with inline helper functions
This increases readability, decreases bug-potential and
thus makes it easier to enhance performance
- don't fear dirty tricks, but always document them properly.
I could probably quote some nice code examples and give
some background on CPU internals and other stuff in order
to make it into a nicely readable yet informative text.
> http://sunsite.unc.edu/LDP/HOWTO/Benchmarking-HOWTO.html
> which does not have any concrete details on tuning the various kernel
> parameters for optimal performance either)
Look in linux/Documentation/sysctl/*. And before you complain
that the docs are outdated -- the new version is in Linus'
pipeline, Alan already has them in his tree.
> There may also be a need to critize the current architecture as
> implemented in the Kernel. An world-class scale Unix requires the
> ability to scale in terms of memory, nos of CPU, nos of processes,
> nos [SNIP]
This is clearly a 2.3 issue. There are many plans already in
the pipeline to achieve this, but a bit of discussion never
hurts. If we manage to decide on what to put into 2.3, the
2.3 cycle can be kept a very short one...
> I therefore proposed that every one of us come together and contributes
> ideas to go into a "Joint Whitepaper on Performance"....essential topics
> I have identified so far (which I wish everyone will contribute
> something) are:
>
> b. Design for Memory Management, Differences in MM among Solaris, AIX
> and HP-UX, Buffer Cache Design in Linux, Lock Management
The discussion about MM should move to linux-mm@kvack.org.
We have already discussed and agreed upon what we should
change for 2.3, please read our mailing list archives for
more info.
> e. Design for CPU scalability
Careful thought has to go into this. Would left-shifting
the timeslice with nr_cpus/4 help as a short-term solution?
Something like that will decrease the amount of task switches
going on, thereby lessening the amount of synchronisation going
on.
Other things will have to wait for 2.3, but form an interesting
discussion nontheless. We might want to postpone a discussion
like this until 2.2.0 is out, however.
> f. Design for Disk Management and Scalability
> g. Design for Network Scalability
I/O clustering is the key word for these things. Doing
that requires larger buffers and support from the MM/VM
subsystem. As with the other points, we might want to
postpone the discussion until 2.2.0 is out. The postponing
is because we want to focus most efforts on bugfixing right
now.
> All these articles solicited should revolved around the topic of
> scalability, robustness, and reliability.
>
> The objective of this self-evaluation exercise is to identify what
> are weakness points in the current kernel implementation and
> hopefully to feedback to kernel implementors so as to create a more
> robust high performance kernel.
Agreed. We really should do a thing like this. An evaluation
and inventory of the current problems have helped the MM/VM
subsystem quite a lot...
> h. Design for Ease of Maintenance - Scalability/Robustness
Another important issue, one which we should keep in mind
when discussing all the other issues.
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/