Performance 2.4.8 is worse than 2.4.x<8

Performance 2.4.8 is worse than 2.4.x<8

[Steve Kieu]

Anyone noticed that?

=====
S.KIEU

_____________________________________________________________________________
http://shopping.yahoo.com.au - Father's Day Shopping
- Find the perfect gift for your Dad for Father's Day

Re: Performance 2.4.8 is worse than 2.4.x<8

[Mike Galbraith]

On Sun, 12 Aug 2001, Steve Kieu wrote:

> Anyone noticed that?

Details?

Here, disk write throughput seems to want some tweaking, and Bonnie
doing it's rewrite test triggers a very large and persistant inactive
shortage which shouldn't be there (imho).

page_launder() is definitely working better than some of the pre8
kernels in that it is no longer laundering the entire dirty list in
one huge gulp.  It is also no longer laundering some random amount.

Under FWIW:  I can find no reason for the existance of either the
launder_loop nor doing synchronous IO.  Here, I remove both regularly
and detect nothing but benefit both in responsivness and throughput.

	-Mike

Re: Performance 2.4.8 is worse than 2.4.x<8

[Steve Kieu]

 --- Mike Galbraith <mikeg@wen-online.de> wrote: > On
Sun, 12 Aug 2001, Steve Kieu wrote:
> 
> > Anyone noticed that?
> 
> Details?

VM is very much improved but it seems to take
resources  to free cached pages.
> Here, disk write throughput seems to want some
> tweaking, and Bonnie

that is what I see

 doing it's rewrite test triggers a very large and
> persistant inactive
> shortage which shouldn't be there (imho).
> 
> page_launder() is definitely working better than
> some of the pre8
> kernels in that it is no longer laundering the
> entire dirty list in
> one huge gulp.  It is also no longer laundering some
> random amount.
> 
> Under FWIW:  I can find no reason for the existance
> of either the
> launder_loop nor doing synchronous IO.  Here, I
> remove both regularly
> and detect nothing but benefit both in responsivness
> and throughput.
> 
>  -Mike
>  

=====
S.KIEU

_____________________________________________________________________________
http://shopping.yahoo.com.au - Father's Day Shopping
- Find the perfect gift for your Dad for Father's Day

Re: Performance 2.4.8 is worse than 2.4.x<8

[Alan Cox]

> Here, disk write throughput seems to want some tweaking, and Bonnie
> doing it's rewrite test triggers a very large and persistant inactive
> shortage which shouldn't be there (imho).

This is one of the reasons I kept the 2.4.7 vm. The 2.4.8 vm is better
than 2.4.8pre but not actually better than the older VM by feel or
measurement on my test boxes

Alan

Re: Performance 2.4.8 is worse than 2.4.x<8

[Rik van Riel]

On Sun, 12 Aug 2001, Alan Cox wrote:

> > Here, disk write throughput seems to want some tweaking, and Bonnie
> > doing it's rewrite test triggers a very large and persistant inactive
> > shortage which shouldn't be there (imho).
>
> This is one of the reasons I kept the 2.4.7 vm. The 2.4.8 vm is better
> than 2.4.8pre but not actually better than the older VM by feel or
> measurement on my test boxes

There are some open-ended questions wrt. the use-once idea,
its implementation and the way the thing has been integrated
with the rest of the kernel.

Some suspect interactions and some things which just aren't
clear yet don't make it seem the best idea to start integrating
the use-once idea in mainli^W-ac yet...

regards,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Performance 2.4.8 is worse than 2.4.x<8

[jogi]

On Sun, Aug 12, 2001 at 11:00:31AM -0300, Rik van Riel wrote:
> On Sun, 12 Aug 2001, Alan Cox wrote:
> 
> > > Here, disk write throughput seems to want some tweaking, and Bonnie
> > > doing it's rewrite test triggers a very large and persistant inactive
> > > shortage which shouldn't be there (imho).
> >
> > This is one of the reasons I kept the 2.4.7 vm. The 2.4.8 vm is better
> > than 2.4.8pre but not actually better than the older VM by feel or
> > measurement on my test boxes
> 
> There are some open-ended questions wrt. the use-once idea,
> its implementation and the way the thing has been integrated
> with the rest of the kernel.
> 
> Some suspect interactions and some things which just aren't
> clear yet don't make it seem the best idea to start integrating
> the use-once idea in mainli^W-ac yet...

Is it possible that this causes the slowdown I see when I benchmark
kernel compilations? Doing make -j2 bzImage modules on 2.4.7 gives:

        User time (seconds): 279.62
        System time (seconds): 22.19
        Percent of CPU this job got: 77%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 6:29.95
        ...
        Major (requiring I/O) page faults: 1085696
        Minor (reclaiming a frame) page faults: 1263226

With 2.4.8 (default bdflush settings):

        User time (seconds): 280.75
        System time (seconds): 21.46
        Percent of CPU this job got: 71%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 7:04.14
        ...
        Major (requiring I/O) page faults: 1085927
        Minor (reclaiming a frame) page faults: 1263289

With 2.4.8 (and 50/75 bdflush settings):

        User time (seconds): 282.20
        System time (seconds): 20.82
        Percent of CPU this job got: 71%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 7:03.27
        ...
        Major (requiring I/O) page faults: 1094004
        Minor (reclaiming a frame) page faults: 1265526

Since 2.4.8 should be better when running short of memory I tried
make -j bzImage modules also, with 2.4.7:

        User time (seconds): 294.16
        System time (seconds): 32.70
        Percent of CPU this job got: 32%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 16:40.38
        ...
        Major (requiring I/O) page faults: 1560301
        Minor (reclaiming a frame) page faults: 1601194

and with 2.4.8 (default bdflush)

        User time (seconds): 293.57
        System time (seconds): 50.55
        Percent of CPU this job got: 24%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 23:35.30
        ...
        Major (requiring I/O) page faults: 1592833
        Minor (reclaiming a frame) page faults: 1556612

System is an Athlon-1.2GHz with 256MB DDR-Ram.


If you want further compilation benchmarks just let me know.


Regards,

   Jogi


-- 

Well, yeah ... I suppose there's no point in getting greedy, is there?

    << Calvin & Hobbes >>

Re: Performance 2.4.8 is worse than 2.4.x<8

[Linus Torvalds]

In article <E15VtnT-0005bM-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>> Here, disk write throughput seems to want some tweaking, and Bonnie
>> doing it's rewrite test triggers a very large and persistant inactive
>> shortage which shouldn't be there (imho).
>
>This is one of the reasons I kept the 2.4.7 vm. The 2.4.8 vm is better
>than 2.4.8pre but not actually better than the older VM by feel or
>measurement on my test boxes

Word of warning: there are some loads on which 2.4.7 will simply lock
up.  If you don't want to take all the new code, at least take the
changes to fs/buffer.c and refill_buffer() or whatever.  With just those
parts it will still end up being pitifully slow in the cases it used to
lock up, but it will end up making progress and eventually recovering. 

(In all fairness, the load to make it go into the bad behaviour is
rather unusual, and as such probably not a huge problem for most people. 
That's obviously also the reason why it wasn't really noticed until now
- but this is, for example, apparently the cause for the "processes
getting stuck in __wait_on_buffer()" bug that I know RedHat also saw
under load). 

That said, me and Marcelo are still working on making sure it's good
under _all_ loads..

			Linus

Re: Performance 2.4.8 is worse than 2.4.x<8

[Rik van Riel]

On Sun, 12 Aug 2001, Linus Torvalds wrote:

> Word of warning: there are some loads on which 2.4.7 will simply lock
> up.  If you don't want to take all the new code, at least take the
> changes to fs/buffer.c and refill_buffer() or whatever.

I'll do my best to merge some of the obviously correct
pieces of VM code from -linus to -ac.

> That said, me and Marcelo are still working on making sure it's good
> under _all_ loads..

I wonder how much you'd be willing to give up in the
common case in order to prevent the system from falling
over under strange loads. Hypothetically speaking, that
is, I don't really have anything in mind yet ;)

cheers,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Performance 2.4.8 is worse than 2.4.x<8

[jlnance]

On Sun, Aug 12, 2001 at 12:52:47PM +0100, Alan Cox wrote:
> > Here, disk write throughput seems to want some tweaking, and Bonnie
> > doing it's rewrite test triggers a very large and persistant inactive
> > shortage which shouldn't be there (imho).
> 
> This is one of the reasons I kept the 2.4.7 vm. The 2.4.8 vm is better
> than 2.4.8pre but not actually better than the older VM by feel or
> measurement on my test boxes

Alan,
    Which kernels are you refering to when you speak of the older VM?

Thanks,

Jim

Re: Performance 2.4.8 is worse than 2.4.x<8

[Alan Cox]

>     Which kernels are you refering to when you speak of the older VM?

2.4.7-ac, which is 2.4.7 like but with certain differences in behaviour and
much harder inode pressure