Re: Ingo's RAID patch for 2.2.18 final?

Sasi Peter (sape@iq.rulez.org)
Wed, 24 Jan 2001 16:05:12 +0100


> > (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/