Re: Ingo's RAID patch for 2.2.18 final?

["Sasi Peter" <sape@iq.rulez.org>]

> > (30+ high speed streams from 4 disks does really need some caching).
> This isn't obvious. Your working may not fit in cache and so the 
kernel
> understand it's worthless to swapout stuff to make space to a 
polluted cache.

But your understanding agrees on that the larger chunks for each stream 
we read into cache, the more efficient for this kind of RAID disk 
structure the read is, thus basically the more cache we have, the more 
bandwidth we can serve. (disks give more data in the same time with 
fewer long reads than with several shorter ones)

So might it have been an accidental behaviour of the previous kernels 
to swap out pages in favor of caching under high I/O pressure, but it 
was certainly a benefical behaviour.

> > Can't say, of these many daemons nothing can be swapped out (and 
should
> > under I/O load)!
> If you run `cp /dev/zero .` on a smart VM nothing must be swapped out 
even if
> it generated nearly the maximal I/O flood possible. It's worthless to 
let a
> polluted cache to grow. It won't help anyways and you'll run slower 
the next
> time you'll have to pagein from swap.
> It _enterely_ depends on the I/O load pattern if it worth to swapout 
or not
> to make space for filesystem cache.

Ok (possibily incorrect, but simple) definition of I/O pressure of mine 
is when the _real_ _physical_ disks are working all the time, pushing 
data out of the box (in this case through the network).

"cp /dev/zero ." is a somewhat different from my case:
- mine is an IRL case (don't know how often a pattern like the "cp" 
case show up IRL)
- Mine is about _reading_ from disks
 
> > Be this, if this is the price for stability.
> As said we can add bits of page aging (that can't destabilize 
anything and it
> will only affect performance behaviour), but I'd prefer to be sure 
you really
> get a slowdown due the new VM behaviour (because more aging if done 
without
> multiqueue O(1) approch can introduces waste of CPU and cachelines in 
kernel
> space), so could you try to kill notes and squid and the other unused 
stuff and
> to see if you return to deliver performance as with the older 
kernels? I still

It might and it should, but actually I gotta have these started in case 
someone drops in for using them. As I understand the only thing this is 
worth trying out for is that maybe even with more cache I will have 
less performance, than before, because in this case to or not to swap 
out dows not really matter. Is this correct? Beacuse I will have to 
have these running anyways...

> miss this important information (last thing you said me was that with 
100mbyte
> in cache it swapouts, and without knowing the details of the I/O 
pattern it

like when decreasing constantly, at reaching that only 100MB cache we 
have left do we start swapping to have more cache, or at least have the 
100MB not less.

> looked sane). After that I'd also like to know what happens with 
2.4.0 that
> uses multiqueue and that is also able to detect pollution and to 
avoid swapping
> out in such case.

What should I test with? (2.4.0/1pre?)

-- SaPE / Sasi Péter / mailto: sape@sch.hu / http://sape.iq.rulez.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/