Linux 版 (精华区)

发信人: netiscpu (说不如做), 信区: Unix
标  题: [M] 有关Linux2.1.9? 的编译时间以及性能的讨论
发信站: 紫 丁 香 (Tue May 19 01:22:04 1998), 转信


        本文整理自Linux-kernel Mailling List

[问题] 2.1.99 is less rusty

Because of the 'mount' problems with the pre-2.1.99 kernels, I didn't
investigate the effects of the mm changes upon the performance of my
pitifully low memory machine.  With 2.1.99 now released, I forced my way
around the 'mount' problem and ran my test script.  I can report that
the 2.1.99 kernel appears to be significantly better than other recent
kernels in the 2.1.xx series, although it is still much worse than
2.0.33 in the rusting department...

The results from the test script which I posted to this list are:

    $ ./test-compile.sh
    Test gcc compile times.
    Linux version 2.1.99 (root@lorentz) (gcc version 2.8.1) #51 Sat May 2 13:06:32 EST 1998
    gcc takes 35.84 seconds before 'find'
    find /home/sys -print | wc  -->  find took 23.64 seconds
      15521   15521  629697
    gcc takes 100.07 seconds after 'find'
    find /home/sys -print | wc  -->  find took 23.52 seconds
      15521   15521  629697
    gcc takes 93.48 seconds after 120 second wait


To summarise the results so far:
         kernel           approx rusting effect
         2.0.33                38 -->  30   (improves!)
         2.1.96                37 --> 263
         2.1.98                43 --> 284
         2.1.99                36 --> 100

(Note that the results are not precise, there is a random variability
 in the results of perhaps 5% -- but don't quote me because I haven't
 actually gathered statistics...)

-- 
-----------------------------------------------------------------------------
Bill Metzenthen        | See http://www.suburbia.net/~billm/ for information
billm@melbpc.org.au    | on an 80x87 FPU emulator, using floating point
billm@suburbia.net     | (particularly on Linux), and code for manipulating
Melbourne, Australia   | the floating point environment on 80x86 Linux.
-----------------------------------------------------------------------------

[回答1]

Good to hear that. It can be better though, I'll provide full
sysctl tuneability for kswapd/free_memory_available() RSN.

> To summarise the results so far:
>          kernel           approx rusting effect
>          2.0.33                38 -->  30   (improves!)
>          2.1.96                37 --> 263
>          2.1.98                43 --> 284
>          2.1.99                36 --> 100

Have you traced where the rusting comes from? Some
kernel statistics (eg. in /proc/sys/kernel/*) can
be of great help too.
(if possible complete with calculations on how much
memory everything takes)

Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page          | Scouting       webmaster |
|        - kswapd ask-him & complain-to guy | Vries    cubscout leader |
|     http://www.phys.uu.nl/~riel/          | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+

[回答2]

Well.. Depending on your test new kernels might always be 'slower' after
the find.. This is still 'too slow' but the 2.0 performance might no have
been as ideal as you think.

2.0 performed better becase some disk blocks got cached.
2.1 performes worse because the dcache gets plumped but not slimmed.

Your benchmark might not benifit from the dcache because it might not
touch enough files for it to matter.

So even if the dcache was clearing out right you'd still lose a little
time for the 'clearing'.. and your benchmark might not benifit from the
dcache leading to a net slowdown.. :)

[回答3]

Did I say 2.0 performance was ideal?  If so, I didn't mean to and I
didn't mean to imply that I thought so.

> 2.0 performed better becase some disk blocks got cached.
> 2.1 performes worse because the dcache gets plumped but not slimmed.

Maybe, I don't claim to understand why the rusting effect occurs...

> Your benchmark might not benifit from the dcache because it might not
> touch enough files for it to matter.
> 
> So even if the dcache was clearing out right you'd still lose a little
> time for the 'clearing'.. and your benchmark might not benifit from the
> dcache leading to a net slowdown.. :)

Hmm, I think that I'd like to avoid the use of the term "benchmark"
here...  Perhaps I should re-iterate what the problem is: in later
kernels on a "low" memory (all relative.. my first personal computer
had 4 kbyte of RAM) machine there is an effect where more and more
swapping occurs as one uses the system.  Thus after a while the system
is very sluggish.  I haven't discovered any way to reverse this
process apart from re-booting.  My little test script is claimed to do
nothing more than accelerate this process (relative to "normal" use)
and to provide a rough metric.

I don't know what causes the effect.  People have suggested it is due
to either memory fragmentation or cache memory not being freed.  I
have looked at the stuff available via /proc and SysRq but it didn't
appear to particularly support either hypothesis.

Linus has announced that the 2.1.xx series will end soon and this is
one problem which I think really should not be knowingly allowed to be
a feature of 2.2.

I don't have the time at the moment to get stuck into solving the
problem myself so I have to hope that the people who have designed the
stuff will fix it (if they feel so inclined and can find the time...).


Cheers,
       Bill

[回答4]

It could still well be that other things are using
too much memory too, like the inodes and the file
structs. We really should reclaim them too...

> I don't know what causes the effect.  People have suggested it is due
> to either memory fragmentation or cache memory not being freed.  I
> have looked at the stuff available via /proc and SysRq but it didn't
> appear to particularly support either hypothesis.

There should be some clues in /proc/slabinfo, /proc/meminfo
and /proc/sys/kernel/{dentry-state,file-nr,inode-state}.
It could just as well be that your system uses/allocates
too many inodes or open files... (which we can't currently
reclaim)

> I don't have the time at the moment to get stuck into solving the
> problem myself so I have to hope that the people who have designed the
> stuff will fix it (if they feel so inclined and can find the time...).

We like seeing our code used by as many people as possible,
so we concentrate major effort into making it possible for
everybody to use it...
Ie: Yes, we do what we can to fix the bugs, although some
more detailed reports (complete with memory usage calculations)
_are_ welcome.
(When you figure out what we should change, we can get
straight to the code and fix stuff)

Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page          | Scouting       webmaster |
|        - kswapd ask-him & complain-to guy | Vries    cubscout leader |
|     http://www.phys.uu.nl/~riel/          | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+

[回答5]

        I'm having the same problems with 2.1.9?. My "benchmark" is simpler and
more subjective than Bill's. I just rebuild the kernel. Under
2.0.[29-33] on this particular machine (a 386-40 with 8M of RAM and 10M
of swap), it takes 3-4 hours to build a kernel. 2.1.9[1-8] couldn't do
it at all - they'd slow down and finally stall out before finishing
(maybe they would have eventually finished... I usually interrupted them
after a few days when the newer kernel came out). 2.1.99 is better - it
actually finished building the kernel, and it only took it about 7.5
hours. As I write this, it's doing the "make modules", and has been
doing so for the last 36 hours. 

        So, in short, this problem is real, not an artifact of Bill's
benchmarking method, and I agree with Bill that, IMHO, this is a serious
problem that shouldn't be allowed into 2.2. One of Linux's strengths has
been that it could run usefully on very low end hardware, and this
behavior removes that capability. Unfortunately, I don't know enough
kernel hacking to fix this myself, so I can't do much more than provide
another data point here.

---
John Campbell
jcampbel@lynn.ci-n.com

[回答6]

Pre-100 _with_ my patch should give you quite a lot of
improvement. 

Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page          | Scouting       webmaster |
|        - kswapd ask-him & complain-to guy | Vries    cubscout leader |
|     http://www.phys.uu.nl/~riel/          | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+


[回答7]

Woah, it takes me only a hour and half to compile kernel *and* modules for
2.1.98 - I have a 486DX4/100 here. Since the compile process is limited by
the bus throughput (bus, not the CPU itself, is at 33MHz), I have to
wonder why your builds takes so long. What version of binutils/gcc are you
using? 

I've noticed an improvement in compiles after I upgraded binutils from
2.8.1.0.15 to 2.9.1.0.3, and rebuilt gcc on top of that. 

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Smoke some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk

[回答8]


You don't mention the amount of RAM you have -- it is critical to the
effect being discussed on this thread.  If you have only 8 Mbyte then
I'd like to know more about the details of your system (disk system
type for example) please.

-- 
-----------------------------------------------------------------------------
Bill Metzenthen        | See http://www.suburbia.net/~billm/ for information
billm@melbpc.org.au    | on an 80x87 FPU emulator, using floating point
billm@suburbia.net     | (particularly on Linux), and code for manipulating
Melbourne, Australia   | the floating point environment on 80x86 Linux.
-----------------------------------------------------------------------------

[回答9]

I have 32MB of memory - but I am going to experiment with 8MB (lilo
mem=8m) Will let you know how I get on.

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Smoke some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk


[回答10]

386's have not-too-good L1 cache (few bytes). Try to turn of L1 of
your 486 and you'll see. 4 hours is pretty goodtime, knowing that it
was 386.

                                                                Pavel
-- 
The best software in life is free (not shareware)!              Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

[完]

--

                              Enjoy Linux!
                          -----It's FREE!-----

※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: mtlab.hit.edu.cn]