>feel while larging tons of data to disk. The culprit is buffer.c and the
>reason 2.2.5 is not stalling is due the set_writetime misfeature that on
>the other side is harming a lot performances in the stock kernel.
Really in the last minutes I've found also some stupid design in my
shrink_mmap() of "all" 2.2.5_arca*.bz2 that may lead to bad performances
and maybe stalls. Unfortunately I was using the bad design of
shrink_mmap() as a feature :(. So with the design fixed, the system runs
less smoothly under swap, but if you are not swapping heavily this new
patch should perform better than arca12.
Anyway I am interested if you could try my last code and make comparison
(I tested it with some my hogtest, but I'll try your testcase very soon).
ftp://e-mind.com/pub/linux/arca-tree/2.2.6_arca1.bz2
It has rbtrees in both page cache and buffer cache and theorically
according to me should perform better than arca12 (at least with plenty of
memory). It's rock solid here.
In the meantime I'll think on how to get the information that I was
getting previously by the old-bad-design of shrink_mmap in order to run
smootly under swap as 2.2.5_arca12 but to continue to perform well as
2.2.6_arca1 when tons of freeable memory is available...
Andrea Arcangeli
PS. in the last days I also cleanedup my tree removing all not-mine
patches, so now it should contains only code written by me (I think
except Ingo get_8254_timer_count() that I merged at the time I developed my
recover-lost-ticks code, and Andi Lock-time /proc/ things that I
merged at the time I did the smp-lock-profiler).
PPS. As just said 2.2.6_arca12.bz2 had a bug that can lead to a kernel
panic while heavily swapping, so if you are using it better to
upgrade to this new patch ;).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/