Re: [PATCH] 2.4.20-rmap15a

[Miquel van Smoorenburg]

In article <[e-mail]>,
Rik van Riel  <[e-mail]> wrote:
>This is a merge of rmap15a with marcelo's 2.4 bitkeeper tree,
>which is identical to 2.4.20-rc4 (he didn't push the makefile
>update).  The only thing left out of the merge for now is
>Andrew Morton's read_latency patch, both because I'm not sure
>how needed it is with the elevator updates and because this
>part of the merge was too tricky to do at merge time; I'll port
>over Andrew Morton's read_latency patch later...

Just FYI:

I've tried this on our peering newsserver, you know, the same one
I tried a couple of 2.5.4X kernels on (Andrew knows ...)

Basically, performance sucks with rmap15a, with or without readlatency2.
See http://stats.cistron.nl/mrtg/html/wormhole.html

Monday  2-dec 16:00 -- Tuesday 3-dec 12:00	rmap15a + rl2
Tuesday 3-dec 12:00 -- Tuesday 3-dec 14:00	rmap15a
Tuesday 3-dec 14:20 -- now			2.4.20 vanilla

As you can see, the server accepted a lot less articles when
running rmap, as a result outgoing bandwidth dropped too.

I have no idea how to find out what the exact cause of this is,
so I didn't (it's still a production server and I can't let
it limp along for a too long period of time) that's why I
started with 'just FYI'. BTW, the server is not into swap - it
just looks like the working set of innd (the main article
accepting process) which includes mmap()s of the history
database is getting pushed out of memory by streaming IO,
which is really bad for performance. 2.4.20 does better on
this, and 2.5 a bit more even (but isn't stable)

Mike.
-- 
They all laughed when I said I wanted to build a joke-telling machine.
Well, I showed them! Nobody's laughing *now*! -- [e-mail]