On Thu, 8 Jun 2000, Andi Kleen wrote:
> Please not that 2.3 itself has significant performance
> regressions for huge bulk writes (there were several threads on
> linux-kernel about that). Partly the still broken page cache
> balance is probably to blame,
Definately. Following age-old Linux tradition I'm currently
re-writing the VM subsystem at the end of the code freeze
period, heavily counting on code beautification and tons of
obviousness to make Linus accept the change.
One interesting thing that's going on is the split in active,
inactive and scavenge queues, where dirty pages will be flushed
when we want to take them off of the inactive list. We're planning
a block->mapping->flush() function for that...
This should be interesting to XFS because it means that you'll
be able to implement allocate-on-flush as a relatively simple
and independant patch that'll just "plug in" the MM subsystem.
Basically my not-yet-compiling code tree that's sitting on my
disk now (need to write a few more functions and then I can
compile and boot it) is ready for allocate-on-flush. The only
thing that needs to be done is the reservation system for
> for other things the elevator (Jens Axboe's per device elevator
> patches seem to cause a huge speedup)
Yup, according to Jens and a bunch of other people this
seems to be sorted out.
These changes should help XFS performance quite a bit. Tuning for
the small changes may want to wait until after the big stuff is
done. Btw, anybody here interested in doing some IO clustering
stuff for the VM subsystem? ;)
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies